Изменения функционала в версии 1.024.4
Порядок установки версии.
Управление рассылкой справочников.
Использование ценников разных видов.
Категории ценников.
Типы ценников.
Назначение категории ценника артикулу.
Скидка на артикул по дисконтной карте.
Фильтр карточек по дополнительным характеристикам.
Функция проверки контрагента счета и дисконтной карты.
Отсылка накладной на корректировку.
Автоматическая рассылка Z отчетов.
Поле «Свойство» в разделе кассовых чеков.
Структура мест хранения.
Редактирование объектов структуры мест хранения
Рассылка объектов структуры мест хранения.
Экспорт чеков в OLAP.
Экспорт привязки налоговых групп к карточкам в OLAP.
Почтовый модуль.
Шифрование физического пакета.
XML фильтр почтового модуля.
Почтовые объекты.
Синхронизация массива объектов.
Часть компонентов версии 1.024.4 использует Microsoft .NET Framework v 2.0. Перед установкой или обновлением версии необходимо обязательно установить среду исполнения Net Framework 2.0. Если среду установить после установки торговой системы, то часть компонентов останется незарегистрированными и будет неработоспособна. В таком случае могут быть получены ошибки вида:
«Класс контроля версий {393266F5-7611-481C-862F-521E24D767C9} не зарегистрирован.
Переустановите .NET компоненты Супермага (Sm.*.dll)»
В свою очередь, программа установки Net Framework 2.0 требует, чтобы предварительно был установлен Microsoft Windows Installer 3.1.
В торговой системе все справочники, с точки зрения почтового модуля, отнесены к одному объекту «Справочник» («RF»). Каждый конкретный справочник при почтовом обмене выступает в качестве экземпляра объекта «Справочник» с идентификатором равным названию таблицы, содержащей собственно справочник.
В торговой системе все справочники поделены на две группы: рассылаемые и не рассылаемые. Рассылаемые справочники могут рассылаться из старшей базы данных в подчиненные, если определено условие автоматической рассылки или явно вызвана функция рассылки.
Настройка автоматической рассылки позволяет либо указать на то, что все рассылаемые справочники должны рассылаться автоматически, либо никакие рассылаемые справочники автоматически не рассылаются.
В ряде случаев представление о том, должен ли справочник быть рассылаемым или не рассылаемым, зависит от организации бизнес процессов и степени самостоятельности объектов сети, в частности, привязка типов ценников к товарам может формироваться на местах либо в центре.
Для рассылаемых справочников введены типы: общий и локальный. Для управления типом справочников создан не рассылаемый справочник «Типы справочников».
Установка флага «локальный» приводит к блокировке, как отсылки справочника, так и его приема.
В тех случаях, когда разные объекты сети обладают разной степенью самостоятельности, объявление справочника локальным в удаленной базе данных позволяет обеспечить самостоятельное ведение справочника в этой базе данных и сохранить централизованное управление остальными объектами сети.
Чтобы справочник успешно пересылался, он должен быть объявлен общим, как в отсылающей базе данных, так и в принимающей.
Для редактирования справочника «Типы справочников» необходимо обладать функциональным правом «Редактирование типов справочников».
В предыдущих версиях системы было предусмотрено три фиксированных категории ценников, чтобы можно было для одного и того же товара напечатать три разных ценника, отличающихся, например, размером или оформлением.
В текущей версии предоставлена возможность создавать категории ценников самостоятельно в таком количестве, которое необходимо для решения маркетинговых задач.
Для управления категориями ценников создан рассылаемый справочник «Категории ценников». Для совместимости с предыдущими версиями системы прежние фиксированные категории заносятся в этот справочник при генерации схемы базы данных или при модернизации схемы. Они получили соответственно названия «Маленький», «Средний», «Большой». Эти категории не являются системными и могут быть изменены или удалены по желанию пользователя. В частности, их названия могут быть изменены в соответствии с реальным назначением категории.
Рассылка справочника осуществляется совместно и как неотъемлемая часть справочника «Типы ценников».
Понятие «тип ценника» используется для логического описания файла ценника и указания его принадлежности той или иной категории ценника. Определение типа ценника и описание файла ценника для него, осуществляется в справочнике «Типы ценников».
В предыдущих версиях для фиксированных категорий ценников существовала привязка по умолчанию к стандартным файлам ценников. Это позволяло печать стандартный ценник в тех, случаях, когда в разделе классификатора товаров для группы товаров для категории ценника не был задан никакой тип ценника. Описание файлов ценников по умолчанию ранее приводились в справочнике «Печатные формы документов» как печатные формы карточки складского учета (тип «CD»).
В текущей версии перечень категорий является нефиксированным и понятие стандартных файлов ценников для категорий по умолчанию более не поддерживается. Соответственно, описание стандартных ценников изъято из справочника «Печатные формы документов» и ценники теперь будут печататься только в том случае, если описание типа ценника явно задано в разделе классификаторов, например, для группы «Все».
При инициализации новой схемы базы данных справочник типов ценников заполняется значениями стандартных файлов ценников для перечня из трех категорий, которые сохранены для совместимости с предыдущими версиями.
Также, для совместимости с предыдущими версиями, при создании новой схемы базы данных и при модернизации схемы базы данных для группы классификатора «Все» для трех категорий ценников задаются типы ценников, соответствующие предыдущему понятию стандартных ценников по умолчанию.
Справочник типов ценников теперь может рассылаться по почте, но для совместимости с предыдущими версиями он помечен как локальный (см. справочник «Типы справочников»). При рассылке справочника «Типы ценников» одновременно, как его часть, всегда отсылается содержание справочника «Категории ценников» и содержание справочника «Дополнительная информация для ценников».
Информация о назначении типа ценника группе классификатора по категориям ценников выделена в отдельный справочник «Типы ценников для групп товаров». Данный справочник не имеет интерфейса в разделе справочников и управляется только через раздел классификатора товаров. Справочник «Типы ценников для групп товаров» может рассылаться по почте, но для совместимости с предыдущими версиями по умолчанию объявлен локальным (см. справочник «Типы справочников»).
Справочник может рассылаться автоматически, если определена автоматическая рассылка общих справочников или вручную из раздела классификатора товаров, если в диалоге «Почтовая рассылка» выбран объект «Типы ценников для групп товаров».
В разделе «Карточки складского учета» на панели детального описания карточки создана новая страница «Ценники» для назначения карточке складского учета персонального типа ценника или персонального текста строк дополнительной информации для ценника.
Если персональное значение типа ценника или текста информации для карточки не задано, то при печати ценника для карточки используются значения, заданные для группы классификатора.
Персональное задание типов ценников или дополнительной информации может быть использовано для визуального выделения в торговом зале отдельных товаров, например участвующих в рекламных мероприятиях, или для предоставления покупателям дополнительной информации, например о программах кредитования, персонально для заданных товаров.
В диалог печати ценников добавлен флаг «Подтверждать успешную печать ценников». Положение флага запоминается персонально для каждого пользователя. По умолчанию флаг установлен, что приводит к необходимости обязательного подтверждения пользователем факта успешной печати экземпляров ценников. Если флаг снят, то диалог подтверждения не выводится, а ценники автоматически помечаются как напечатанные.
Персональная информация о типах ценников для артикулов и строки персональной информации для ценников пересылаются по почте либо автоматически, если в почтовом модуле определена автоматическая отсылка объектов: «Типы ценников для артикулов» («AP») и/или «Дополнительная информация для ценников» («AI»), либо вместе с карточкой товара при ручной отсылке карточки при условии, что справочник «Типы ценников» объявлен общим для пересылки.
Для назначения одного и того же типа ценника множеству артикулов одновременно необходимо выбрать функцию «Изменение ценников» в диалоге «Обработка карточек» (кнопка «Обработать»). Для обрабатываемых карточек можно установить или убрать персональное значение типа ценника.
В разделе фильтра карточек для поиска и отбора артикулов по типу ценника создана страница «Ценники». Условия фильтра позволяют отобрать карточки с указанным типом ценника, либо карточки, для которых персональный тип ценника не установлен.
В разделе «Карточки складского учета» на панели детального описания карточки создана новая страница «Скидки по ДК» для назначения карточке складского учета персональной величины скидки на артикул для типа дисконтной карты или для дисконтной карты.
Скидка на артикул для дисконтной карты не может быть передана в кассы типа УКМ2.
По умолчанию на странице отображаются только типы дисконтных карт, для которых можно задать величину скидки для каждого вида цены отдельно. Если персональная скидка для артикула не задана, то на него действует скидка, заданная для группы классификатора.
Чтобы определить скидку для артикула для конкретной дисконтной карты необходимо установить курсор на нужный тип дисконтных карт и отобрать дисконтные карты, нажав кнопку «Отобрать диск. карты». Затем, для требуемой дисконтной карты можно определить персональное значение скидки на артикул.
Для пересылки по почте скидок на артикул для типа дисконтных карт и для дисконтной карты созданы почтовые объекты «Скидки по типам дисконтных карт для артикулов» («DR») и «Скидки по дисконтным картам для артикулов» («DI»). Скидки могут пересылаться автоматически или вручную вместе с артикулом, если при рассылке артикула в диалоге «Рассылка карточек» установить флаг «Скидки по дисконтным картам».
Скидки для артикулов автоматом или при ручной рассылке в конкретную базу рассылаются только в те базы данных, которые содержат места хранения с видами цен, которым дана скидка.
Для назначения одной и той же величины скидки множеству артикулов одновременно необходимо выбрать функцию «Изменение скидок» в диалоге «Обработка карточек» (кнопка «Обработать»).
Для обрабатываемых карточек можно установить или убрать персональное значение скидки для типа карточки и/или для дисконтной карты.
В разделе фильтра карточек для поиска и отбора артикулов по критерию наличия персонального значения скидки для дисконтных карт создана страница «Скидки». Условия фильтра позволяют отобрать карточки со скидками, значения которых соответствуют заданному диапазону скидок, либо карточки, для которых персональные значения скидок не установлены. Флаги условия фильтрации «Скидка меньше/больше скидки на группу» позволяют отобрать артикулы, скидка которых соответственно меньше или больше скидки, назначенной на группу товаров.
Внесены изменения в отчет «Каталог скидок по дисконтным картам». В диалог старта отчета добавлена опция «Показать артикулы с персональной скидкой». При выборе этой опции в отчете дополнительно выводятся артикулы, имеющие персональные значения скидок для типа дисконтных карт или для дисконтной карты.
Фильтр артикулов по значениям дополнительных характеристик товара расширен поиском артикулов по части значения дополнительной характеристики, а именно:
Способ поиска – «Точно», «Префикс», «Суффикс» или «Часть», может быть задан отдельно для каждой дополнительной характеристики.
Для документа «Счет» реализована функция проверки 156 «Запрет выставления счёта при несовпадающих контрагентах счета и д/к». По умолчанию функция имеет режим «Предупреждение».
Функция проверяет одинаковость контрагента документа и контрагента дисконтных карт, зарегистрированных в документе для предоставления скидки. Проверка осуществляется при выставлении счета.
Если дисконтная карта не имеет контрагента, то ее применение в счете считается корректным, и в этом случае предупреждение не выдается.
Для документов «Приходная накладная», «Расходная накладная» и «Накладная на перемещение» реализована функция отсылки документа на корректировку.
Отсылка документа на корректировку происходит только в те базы данных, которые содержат места хранения документа. Произвольный выбор баз данных для отсылки документа на корректировку недоступен.
Для отсылки документа на корректировку необходимо иметь право на функциональную роль «Отсылка на корректировку».
При отсылке документа на корректировку документ отмечается системным флагом «требует корректировки» и одновременно ставится в очередь на отсылку. Флаг «требует корректировки» позволяет понижать статус документа для дальнейшей его корректировки при наличии права на функциональную роль «Понижение статуса документов, требующих корректировки». Если у пользователя при этом отсутствует право на понижение статуса документа, то статус прочих документов (без флага «требует корректировки») понизить он не сможет.
Флаг «Требует корректировки» сбрасывается при любом повышении статуса документа.
В краткий и подробный фильтры накладных добавлена опция «Требует корректировки», которая позволяет отобрать только те документы, которые помечены флагом «Требует корректировки».
Для объекта «Кассовый отчет» («CZ») реализована процедура ручной и автоматической рассылки. Отсылка кассового отчета подразумевает отсылку всех чеков, относящихся к одному Z отчету.
При автоматической рассылке кассовые отчеты ставятся в очередь на отсылку и рассылаются не в момент приема кассового отчета от кассы, а в момент успешного создания на их основе кассового документа.
При ручной рассылке можно отослать любой закрытый кассовый отчет. Оперативные чеки не рассылаются.
Для ручной рассылки кассовых отчетов необходимо иметь право на функциональную роль «Кассовый чек: Рассылка по почте».
В разделе «Кассовые чеки» в перечень полей спецификации чеков добавлено поле «Свойство» для отображения значения свойства товара, зарегистрированного кассой.
По умолчанию поле не отображается. Для включения отображения поля необходимо нажать кнопку «Поля…» в заголовке раздела и в диалоге «Выбор показываемых полей» на странице «Спецификация» отметить флажок «Свойство».
Формат записи значения свойства в чеках отличается от записи в торговой системе. Для одномерных свойств внешний вид записей совпадает, для многомерных свойств запись в чеке выглядит как строка с перечнем значений, разделенных вертикальной чертой.
В предыдущих версиях системы структура мест хранения могла редактироваться только для тех мест хранения, которые являлись локальными для базы данных. Пересылка структуры мест хранения разрешалась только из подчиненной в старшую базу данных. Такое ограничение было связано с необходимостью защиты настроек управления кассами от случайного изменения извне. В версии 1.024.3 содержание почтового объекта «Структура мест хранения» претерпело изменение и было разделено на несколько почтовых объектов:
Логика почтового обмена в версии 1.024.3 осталась без изменения.
В текущей версии снято ограничение на редактирование структуры места хранения удаленной базы данных. Для защиты от случайного изменения структуры нелокального мест хранения созданы дополнительные функциональные роли:
Соответствующее изменение внесено в интерфейс – снят запрет на вход в режим редактирования для нелокальных мест хранения.
В текущей версии снято ограничение на направление рассылки структуры места хранения. Объекты структуры могут пересылаться как из подчиненной в старшую базу данных, так и обратно.
Выбор направления пересылки зависит от организации процессов управления и от степени централизации этих процессов. В любом случае, направление рассылки для каждого типа объекта должно быть однозначно определено, и поддерживаться административно. Произвольный обмен данными может привести к нарушениям в работе магазина.
Для защиты от случайной передачи в иные базы данных информации о структуре нелокального места хранения создана дополнительная функциональная роль:
Для централизованного управления персоналом магазина для должностей кассиров и продавцов-консультантов реализованы функции автоматической рассылки для объектов «Кассир» и «Продавец-консультант».
Все прочие объекты структуры места хранения могут пересылаться вручную при наличии у пользователя соответствующих прав.
В диалог ручной рассылки информации о структуре мест хранения внесены изменения для выбора конкретных типов объектов, требующих рассылки, а именно:
В экспорт типа данных «Кассовые чеки (OLAP)» добавлены колонки «№ позиции» и «Операция.Код», которые соответствуют понятиям – номер позиции в чеке и операция чека.
Коды операции в чеке не совпадают с кодами операций торговой системы и зависят от программы ККМ. Супермаг УКМ возвращает в чеке следующие номера операций:
0 - возврат за наличные;
1 - продажа за наличные;
2 - возврат по банковской карте, работающей с дополнительной или вспомогательной валютой;
3 - продажа по банковской карте, работающей с дополнительной или вспомогательной валютой;
4 - возврат по банковской карте, работающей с базовой валютой;
5 - продажа по банковской карте, работающей с базовой валютой.
В экспорт в OLAP добавлен новый тип данных «Привязка налогов к карточкам».
В экспорте выгружаются следующие данные о привязке налоговых групп к артикулу:
Выгрузка может быть ограничена только теми данными, которые действительны для заданной даты или в заданном диапазоне дат.
Для ограничения выгрузки по датам необходимо задать даты документов «с» и «по» в диалоге «Экспорт данных». Под датами документов в данном случае будут пониматься даты, в диапазоне которых налоговые группы были действительны для артикулов. Например, если задать дату «с» и дату «по» равную текущей дате, то в выгрузку для каждого артикула попадет только та налоговая группа, которая сейчас действует на артикул.
Для защиты информации от несанкционированного доступа на этапе ее пересылки между двумя базами данных введено шифрование тела физического пакета криптоустойчивым алгоритмом. Шифрование реализовано для стандартного фильтра.
Для определения состояния файла физического пакета для него введены следующие расширения:
SFP – несжатый нешифрованный,
SFPZ – сжатый нешифрованный,
SFPP – несжатый шифрованный,
SFPX – сжатый шифрованный.
Для включения режима шифрования необходимо ввести пароль шифрования в диалоге описания внешней базы данных на странице «Конфигурация» почтового модуля. Отсылающие и принимающие почтовые модули обязаны иметь одинаковый пароль для шифрования и дешифрования пакетов для обмена данными между двумя заданными базами данных.
Нешифрованные пакеты могут приниматься независимо от того, задан ли в принимающей базе данных баз данных пароль шифрования или нет. Шифрованные пакеты могут приниматься только, если пароли заданы и совпадают.
Создан XML фильтр почтовых пакетов. XML фильтр позволяет осуществлять обмен почтовыми объектами, используя файлы формата XML. Обмен может осуществляться с любыми программами, которые будут в состоянии поддержать данный формат обмена.
Для включения XML фильтра для почтового обмена необходимо в диалоге настройки параметров базы данных в почтовом модуле, выбрать формат обмена «xml – Стандартный XML фильтр» вместо «sm2000 – Стандартный фильтр».
Один XML файл может содержать информацию о нескольких почтовых объектов, которые могут быть как одного, так и разного типов, например, карточки, документы, контрагенты и т.д. Один почтовый объект должен быть полностью размещен в одном почтовом файле и не может быть разнесен на несколько файлов.
XML фильтр может быть использован для пересылки любых информационных объектов, исключая объекты типа: массив объектов (OA) и команда (RQ). Эти объекты не используются в обмене по XML протоколу из-за потенциальной опасности разрушения информации в базе данных при некорректном создании объектов внешними системами.
Структура почтового объекта, например, карточки складского учета, не может быть произвольной. Его структура обязана быть согласована со структурой информационного объекта в базе данных. Для согласования содержания XML файлов используются файлы описания XML схемы – XSD файлы. Будучи созданы один раз, файлы описания XML схемы становятся стандартом обмена, который не зависит от версии базы данных торговой системы и позволяет осуществлять обмен без изменения структуры почтовых пакетов при смене версии Супермага.
Для каждого почтового объекта, подлежащего обмену, должен быть создан свой файл описания XML схемы. Название файла должно соответствовать следующему правилу <Тип объекта>.XSD, где «тип объекта» - двухбуквенный код информационного объекта, например, для карточки складского учета файл описания XML схемы должен иметь следующее имя: CD.XSD
Файлы описания XML схемы для всех типов объектов, участвующих в обмене, должны быть помещены в один каталог. Путь к этому каталогу задается в настройках XML фильтра в почтовом модуле: строка «Путь к папке со схемами» в таблице «Параметры фильтра».
Пример полного описания структуры всех доступных почтовых объектов можно получить в административном модуле в разделе «База данных», на странице «Утилиты», кнопка «Создание схемы данных для XML фильтра».
По умолчанию для размещения файлов XML схем предлагается подкаталог каталога Data вида: Схема_XML_номер версии БД.
Например:
…\SM2000\Data\Схема_XML_1.024.4
После исполнения процедуры в указанном каталоге будут созданы файлы описания XML схем для всех почтовых объектов. Схема объектов будет соответствовать текущей структуре базы данных. Для каждой новой версии системы эта структура может изменяться, как правило, в сторону расширения, то есть объекты приобретают новые таблицы или таблицы приобретают новые поля.
Это не означает, что при почтовом обмене необходимо каждый раз при смене версии адаптировать протокол обмена к новой структуре. Адаптацию необходимо проводить только в случае радикальных изменений, например, когда происходит дробление почтового объекта на ряд новых почтовых объектов или осуществляется полная реорганизация объекта.
В стандартном случае достаточно определиться в перечне атрибутов объекта, необходимых для обмена, зафиксировать их в файлах схемы и более не менять. Генерацию файлов XML схемы можно использовать, чтобы получить пример или шаблон для разработки собственных схем почтовых объектов.
Конечный список пользовательских файлов схемы данных может содержать неполный набор объектов, их таблиц и полей. Типы полей в схеме данных XML также могут не соответствовать типам данных схемы почтового объекта в виртуальном пакете. В этом случае будет выполняться преобразование данных. Содержание данных должно гарантировать возможность корректного преобразования типов данных. При наличии в файле схемы данных полей, не имеющихся в схеме почтового объекта Супермага, при приеме эти поля будут игнорироваться, а при отсылке в эти поля будет выгружаться значение по умолчанию или null значение.
Настройки XML фильтра:
Шифрование файлов XML фильтром не осуществляется.
Из объекта XD "Скидки по группам товаров" выделен почтовый объект LD "Пределы скидок по группам товаров".
При автоматической рассылке рассылаются только те объекты, значение которых было изменено. При ручной рассылке рассылаются все объекты обоих типов.
Из объекта RV "Переоценки" выделены почтовые объекты RA "Максимальные переоценки" и RI "Минимальные переоценки".
При автоматической рассылке рассылаются только те объекты, значение которых было изменено. При ручной рассылке рассылаются все объекты всех типов.
Архитектура почтового модуля предназначена, прежде всего, для передачи в удаленную базу и приема из удаленной базы данных информационных объектов и для синхронизации содержания этих объектов в двух или более базах данных. В частном случае, при наличии функции автоматической рассылки для объекта, при удалении объекта в исходной базе данных поддерживается также отсылка команды на удаление информационного объекта. В случае если речь идет о некотором перечне или списке объектов, то поддержание синхронного состояния списка объектов в двух или более базах данных осуществляется не собственно почтовым модулем, а правильной последовательностью посылки как самих объектов, в случае их создания или изменения, так и команд на удаление объектов при их удалении.
Если по какой-либо причине процесс передачи информации о последовательных изменениях в состоянии объектов из некоторого списка будет содержать пропуски, то состояния списка объектов в разных базах данных может стать разным, притом, что содержание каждого из объектов, которые были пересланы, будет одинаковым. Например, при отказе от автоматической рассылки, и при ручной рассылке объектов расхождение в состоянии списков образуется в случае удаления объектов в исходной базе.
В текущей версии и в ряде предыдущих версиях были произведены изменения в составе и перечне почтовых объектов для уменьшения трафика почтовой рассылки, например, из состава артикула товаров были выделены штриховые коды как самостоятельные объекты, наценки, уровни торговых запасов и т.д. Дробление почтовых объектов увеличивает вероятность рассогласования состава перечней этих объектов.
В текущей версии создан новый тип почтового объекта «Массив объектов». Массив объектов описывает тип объектов и условие отбора перечня объектов для синхронизации состава списка, а также содержит перечень объектов, который имеется в отправляющей базе данных. Прием массива объектов означает удаление в принимающей базе данных всех объектов, которые подпадают под условие отбора и отсутствуют в полученном списке объектов.
Отсылка массивов объектов встроена в почтовую отсылку групп объектов, объединенных общим условием.
Отсылка массивов объектов присутствует в ручной рассылке следующих объектов:
1) При рассылке артикула для тех объектов, которые отсылаются вместе с артикулом полным перечнем, а именно:
При отсылке перечня объектов, связанных с группой классификатора:
2) XC - Наценки по группам товаров
3) При отсылке переоценок по группам товаров:
4) RR - Правила округления цены
5) При отсылке скидок по группам товаров:
При отсылке чеков кассового отчета:
6) CZ - Кассовый отчет
При отсылке объектов структуры места хранения для места хранения:
7) SC – Кассир
8) SS – Продавец-консультант
9) DG – Группа отделов
10) DU – Отдел
11) PZ – Производственный участок
Изменения функционала в версии 1.024.5
Накопительные скидки.
Активность покупателя.
Рассылка объектов из подчиненной базы в подчиненные базы данных.
Формулы расчета накопительных скидок.
Накопительный тип дисконтных карт.
Загрузка накопительной скидки в кассу.
Отчет «Активность покупателя».
Дополнительные характеристики дисконтных карт.
Справочник банков. Счета контрагентов.
Справочник «Классификатор 1-торг».
Фильтр карточек. Отбор по условию «остаток не равен нулю».
Контрагенты для печати накладных.
Вложения и метки документов Заказ и Складское требование.
Колонка «Остаток» в документе Заказ.
Контракт на закупку. Поле «Рекомендованная розничная цена».
Контракт на закупку в варианте локализации BY.
Приходные накладные в варианте локализации BY.
Платежные документы. Функция «Коррекция сумм».
Функции проверки документов производства.
Прием информации из касс об обслуженных кредитных картах.
Расписание работы кассового модуля.
Экспорт данных в OLAP.
Почтовый модуль. Пакет подтверждения в XML формате.
Реализована поддержка накопительных скидок для розничных клиентов, то есть скидок, величина которых зависит от предыдущей активности клиента и которые предоставляются клиенту при совершении покупки через ККМ.
Под розничным клиентом понимается покупатель с дисконтной картой. Дисконтная карта выступает в роли идентификатора розничного клиента. То есть если картой пользуется несколько человек, то все они считаются одним клиентом. Если один человек пользуется несколькими картами, то каждая карта будет выступать в роли самостоятельного покупателя.
Под активностью розничного покупателя понимается количество покупок и/или сумма покупок, совершенных розничным клиентом к моменту оформления очередной покупки. То есть количество и/или сумма покупок, совершенных покупателем с предъявлением дисконтной карты.
Под накопительной скидкой понимается скидка в процентах от цены товара, величина которой зависит от суммарной активности покупателя за указанный промежуток времени.
Для определения активности розничного покупателя к моменту совершения очередной покупки в магазине необходимо иметь информацию о его предыдущих покупках, как в текущем магазине, так и во всех иных магазинах сети, в которых покупатель использовал дисконтную карту.
Для сбора информации об активности покупателя создана структура данных в виде статистики «Активность покупателя».
Статистика «Активность покупателя» не совпадает со схожей статистикой «Продажи по дисконтным картам» кассового документа. Статистика «Активность покупателя» не привязана к кассовому документу и содержит информацию об артикулах из кассовых чеков без каких-либо преобразований. То есть артикулы упаковок, наборов и т.д. сохраняются в данном случае без изменений.
Статистика «Активность покупателя» позволяет сохранять для каждой дисконтной карты информацию следующего вида: код дисконтной карты, дата операции, место хранения, артикул, сумма покупок с учетом возвратов, количество покупок с учетом возвратов.
В статистику попадают, в том числе, покупки, по которым не предоставлялась скидка по дисконтной карте, но которые были совершены при предъявлении дисконтной карты.
Под количеством покупок понимается количество позиций чека, а не количество товара. Сумма покупок - это сумма, уплаченная покупателем за покупку, то есть стоимость товаров с учетом всех предоставленных скидок.
При возвратах товара не в день покупки величина активности покупателя может приобретать отрицательные значения.
Функция сбора статистики «Активность покупателя» может выполняться автоматически в момент создания кассового документа. Статистика «Активность покупателя» не связана с кассовыми документами и является самостоятельным объектом системы. Выполнение функции сбора статистики привязано к процедуре генерации кассовых документов из соображений адекватности данных об активности покупателя данным кассовых документов о кассовой реализации.
Автоматический сбор информации об активности покупателя является опциональным. В тех случаях, когда накопительные скидки не используются и информация такого рода не представляет интереса, собирать статистику не надо.
Управление включением/выключением сбора статистики «Активность покупателя» осуществляется в административном модуле в разделе «База данных» на странице «Конфигурация» в группе параметров «Касса» в секции «Статистика».
По умолчанию сбор статистики отключен.
Для сбора статистики по данным предыдущих периодов имеется функция «Расчет активности покупателя» в разделе кассовых чеков.
Для пересылки по почте статистики «Активность покупателя» создан почтовый объект «AT» «Активность покупателя». Почтовый объект состоит из одной строки таблицы статистики. Объект пересылается автоматически при изменении или создании. Для ручной отсылки объекта интерфейс отсутствует. В случае необходимости отослать объект повторно, необходимо выполнить функцию «Расчет активности покупателя» в разделе кассовых чеков.
В предыдущих версиях системы топология рассылки почтовых пакетов могла быть только однонаправленной. При многоуровневой организации баз данных пакет мог передаваться либо только по направлению от подчиненной базы данных к старшей базе данных, проходя через промежуточные базы, расположенные в порядке роста старшинства, либо от старшей базы данных по направлению к подчиненной базе данных, проходя через промежуточные базы, расположенные в порядке уменьшения старшинства.
В текущей версии реализована возможность пересылки объекта от одной подчиненной базы данных к другой подчиненной базе данных через общую старшую базу данных. Для этих целей внесены изменения в настройки почтового модуля.
На странице «Параметры» в таблицу правил рассылки для описания правил сквозной пересылки добавлена колонка «Из подчиненной в подчиненную». Названия колонок «Сквозная в старшую» и «Сквозная в подчиненную» заменены соответственно названиями «Из подчиненной в старшую» и «Из старшей в подчиненную».
Установление правила «Из подчиненной в подчиненную» приводит к тому, что объект, принятый из подчиненной базы данных будет переслан в другие подходящие подчиненные базы данных. Подходящей считается такая база данных, которая может быть определена как база данных назначения, исходя из места хранения объекта (если объект содержит место хранения в качестве атрибута) или, исходя из общих правил поведения объектов. В последнем случае объект, пришедший из подчиненной базы данных, может быть переслан в несколько других подчиненных баз данных так же, как если бы он пришел из старшей базы.
При пересылке объекта, пришедшего из подчиненной базы, в другие подчиненные базы, объект не ставится в очередь на отсылку в ту базу, из которой он пришел, даже если такая база будет определена как подходящая для рассылки.
Для рассылки информации об активности покупателей из каждого магазина в каждый магазин, необходимо во всех магазинах настроить автоматическую рассылку объектов «AT Активность покупателя» в старшую базу данных и во всех базах данных, которые управляют базами магазинов, настроить пересылку «из подчиненной в подчиненную». Если структура имеет более двух уровней, то дополнительно в управляющих базах данных необходимо настроить пересылку объектов из подчиненной базы в старшую базу и из старшей базы в подчиненную базу.
Таким же образом можно рассылать, например, информацию о штриховых кодах, если штриховые коды задаются непосредственно в магазинах.
Для описания формул расчета накопительных скидок создан справочник «Накопительные скидки» в разделе «Справочники».
Формулы расчета являются ступенчатыми, то есть формулы задают пороговое значение условия и величину скидки, которое будет действовать при выполнении условия.
Каждая формула описывается названием и может содержать перечень условий и скидок.
В качестве условия может выступать сумма предыдущих покупок (с учетом предоставленных скидок) и/или количество предыдущих покупок (количество позиций в чеках по ранее совершенным покупкам).
Если заданы оба вида условий, то скидка предоставляется покупателю, если соблюдены оба условия.
Если в формуле имеется ряд записей с одним видом условия, то покупателю предоставляется та скидка, которая соответствует максимальному выполненному значению условия, например:
Сумма предыдущих покупок клиента составила 15000 руб. Покупателю будет предоставлена скидка 3%.
Если в формуле имеются записи с обоими видами условия, то покупателю будет предоставлена скидка, которая соответствует записи с наибольшими значениями выполненных условий. То есть, во-первых, рассматриваются только те записи формулы, у которых выполнены оба условия, во-вторых, среди записей с выполненными условиями выбирается запись, у которой значения условия имеют максимальную величину. Если по разным условиям такая запись своя, то среди двух записей выбирается та, по которой скидка имеет наибольшее значение. Например:
Если сумма предыдущих покупок составила 900 руб. и количество покупок составило 30, то покупателю будет предоставлена скидка 2%. Если сумма покупок 2500 руб. и количество покупок 30, то среди двух возможных вариантов 2. и 3. будет выбран вариант 3. со скидкой 4%.
Для типа дисконтных карт введен новый флаг «Накопительная скидка». При установленном флаге «Накопительная скидка» для типа дисконтных карт все карты типа становятся накопительными дисконтными картами. Флаг устанавливается в разделе «Скидки» на странице «Дисконтные карты».
Для типа дисконтных карт с флагом «Накопительная скидка» можно назначить период времени в днях, за который будет суммироваться активность покупателей. Для случая, когда период не ограничен, количество дней устанавливается в ноль. Период времени расчета активности покупателей не имеет смысла для обычных типов дисконтных карт, то есть когда флаг «Накопительная скидка» не установлен. Прочие атрибуты типа дисконтных карт действуют независимо от значения флага «Накопительная скидка». Например, процент скидки типа дисконтной карты будет предоставлен покупателю при предъявлении накопительной дисконтной карты, если для товара не определено никакой другой скидки.
Для накопительных типов дисконтных карт можно назначить формулу расчета скидки отдельно по группам товаров, таким же образом, как назначаются скидки по группам классификатора для обычных типов дисконтных карт. Формулы расчета назначаются группе классификатора для типа дисконтных карт на странице «Скидки по ДК». Одновременное назначение фиксированного значения скидки для группы классификатора и формулы расчета скидки не поддерживается.
Для накопительных типов дисконтных карт не предусмотрено назначение персональных формул расчета для отдельных артикулов. Соответственно, в разделе карточек складского учета на странице «Скидки по ДК» показываются только те типы дисконтных карт, для которых не установлен флаг «Накопительная скидка».
Присвоение группе классификатора формулы расчета скидки означает, что при продаже того товара, который принадлежит этой группе классификатора или ее подгруппам, скидка для товара будет рассчитана по заданной формуле. При этом активность покупателя будет определяться по сумме продаж всех товаров, купленных розничным клиентом, а не только по продажам товаров из указанной группы классификатора.
При установке флага «Накопительная скидка» для типа дисконтных карт информация о скидках для типа и о скидках для дисконтных карт типа по группам классификатора не уничтожается, но становится недоступной для использования. При снятии флага использование данных о скидках восстанавливается.
Назначение формул расчета накопительных скидок типу дисконтных карт рассылается по почте вместе с типом дисконтной карты.
При загрузке информации в кассу для типа касс УКМ2 имеется возможность передать значение скидки для дисконтной карты или группы дисконтных карт с одинаковым префиксом для группы товаров. Средства для передачи информации об активности покупателей и условиях и формулах расчета отсутствуют.
Для поддержки накопительных дисконтных карт при работе с кассами по протоколу УКМ2 в торговой системе реализован расчет величин скидок для накопительных дисконтных карт и загрузки их в кассы.
Расчет ведется только в том случае, когда обмен с кассами ведется по протоколу УКМ2. Предполагается, что при использовании иных протоколов, в кассу будут передаваться данные для расчета, а не результат расчета. В таком случае расчет скидок в торговой системе вестись не будет. Расчет будет проводиться кассой и только тогда, когда дисконтная карта будет предъявлена покупателем для расчета. Это позволит обеспечить процесс продажи актуальной информацией о величинах скидках без избыточного потребления вычислительных ресурсов.
Поскольку заранее не известно, какие дисконтные карты будут предъявлены покупателями, то при загрузке касс по протоколу УКМ2 величина накопительной скидки должна быть известна для всех дисконтных карт накопительных типов. Это условие приводит к большой избыточности расчета. Для сокращения времени расчета и, соответственно, времени подготовки данных для загрузки касс, расчет ведется:
Дата начала суммирования активности покупателя меняется при переходе через 00 часов 00 минут всякий раз, если для типа дисконтных карт задано ненулевое значение количества дней для оценки. То есть, если для типа дисконтных карт задано суммировать активность покупателей за последние несколько дней, например, за 30 дней, то при первой загрузке касс после начала суток расчет скидок будет производиться для всех накопительных дисконтных карт этого типа. Далее в течение суток расчет будет производиться только для карт, по которым активность покупателей изменилась.
Тип загрузки касс – полный или инкрементальный не влияет на тип расчета накопительных скидок. То есть при полной загрузке касс расчет накопительных скидок может не вестись вовсе, если не выполнено ни одно из условий старта расчета.
Значения накопительных скидок сохраняются в таблицах, отличных от таблиц для назначения и хранения скидок для обычных карт. Накопительные скидки не рассылаются по почте и не могут быть случайно замещены скидками, назначенными дисконтным картам директивно в другой базе данных.
Для контроля состояния активности покупателя за период времени создан отчет «Активность покупателя». Отчет относится к категории магазинных отчетов.
Отчет выполняется по данным статистики активности покупателя. Отчет выполняется за заданный период времени. В диалоге старта отчета можно указать номер дисконтной карты или перечень дисконтных карт, по которым требуется просмотреть статистику. В качестве опции отчета можно указать одну или несколько групп классификатора товара.
В отчет выводится информация вида:
Для каждой дисконтной карты показывается дата операции, место хранения, сумма продаж, количество позиций в чеках.
Отчет всегда выполняется с сортировкой по датам операции.
В режиме «Детально по артикулам» дополнительно выводятся артикулы товаров.
Для дисконтных карт созданы дополнительные характеристики дисконтных карт аналогичные таким же характеристикам для карточек складского учета, контрагентов и мест хранений.
Способ использования и назначение дополнительных характеристик дисконтных карт полностью идентичны назначению дополнительных характеристик других информационных объектов. Это самостоятельное создание пользователями торговой системы атрибутов объекта, которые отвечают конкретным потребностям технологических процессов учета или управления. Для дисконтных карт это может быть, в частности, атрибуты анкеты покупателя – владельца дисконтной карты.
Для создания дополнительных характеристик создан справочник «Дополнительные характеристики дисконтных карт». В отличие от других справочников дополнительных характеристик, в справочник для дисконтных карт добавлено поле «Номер п/п». Поле предназначено для определения строгого порядка отображения строк с характеристиками в интерфейсе ввода значений характеристик для дисконтной карты.
Поле «Номер п/п» явным образом не редактируется. Порядковый номер строки управляется положением строки справочника. Строка справочника может передвигаться вверх или вниз по списку строк с помощью кнопок «Вверх» и «Вниз». Окончательно расположение строк с характеристиками в справочнике будет определять порядок вывода характеристик в интерфейсе ввода их значений при работе с дисконтными картами.
Справочник рассылается по почте вручную или автоматически по факту изменения, если имеются соответствующие настройки почтового модуля.
В разделе «Скидки» на странице «Дисконтные карты» внесены изменения для редактирования значений дополнительных характеристик дисконтных карт. В таблицу списка дисконтных карт добавлена колонка «Дополнительные характеристики» с кнопкой, которая вызывает диалог ввода значений характеристик. Для просмотра значений характеристик непосредственно в таблице отобранных дисконтных карт реализована возможность добавлять поля с характеристиками в таблицу. Поля добавляются или удаляются из таблицы в диалоге настройки полей, который вызывается кнопкой «Поля…». Настройка полей сохраняется для каждого пользователя системы отдельно.
Значения дополнительных характеристик дисконтных карт пересылаются по почте вместе с объектом «Дисконтная карта».
Для хранения информации о кредитных учреждениях создан справочник «Банки». Для кредитного учреждения можно зарегистрировать следующие атрибуты:
Справочник является централизованным и может рассылаться по почте вручную или автоматически по факту изменения, если имеются соответствующие настройки почтового модуля.
Ранее информация о банках хранилась в разделе контрагентов как атрибуты контрагента на странице «Общие». В текущей версии данные о банках контрагента вынесены на отдельную страницу «Счета», где контрагенту можно поставить в соответствие несколько банков из справочника банков или несколько счетов одного банка. Счет и банк, атрибуты которого должны печататься в счетах и платежных документах, должен быть отмечен флагом «Актуальный счет».
При переходе от младших версий торговой системы к текущей версии данные о банках переносятся из раздела контрагентов в справочник банков, и контрагентам автоматически присваивается банк и счет, в соответствии с прежними данными. После модернизации схемы необходимо проверить содержание справочника банков. Если один и тот же банк у разных контрагентов имел различающиеся названия, например, дополнительную точку, то в справочник попадет два банка.
Создан новый справочник «Классификатор 1-торг». Структура справочника повторяет структуру справочника «Классификатор 3-торг». Справочник предназначен для группирования артикулов в соответствии с требованиями статистических отчетов.
Справочник имеет следующие поля:
В разделе «Классификатор товаров» на страницу «Узел» добавлен атрибут «Код 1-торг». Присвоение группе классификатора товаров значения группы 1-торг используется при создании новой карточки складского учета. Новая карточка принимает значение кода 1-торг из группы классификатора.
В разделе карточек складского учета создана новая страница «Классификация». На страницу помещен интерфейс для задания группы классификатора 1-торг для карточки складского учета. На эту же страницу перенесен интерфейс для назначения карточке группы классификатора 3-торг со страницы «Карточка» и интерфейс назначения карточки номенклатурам товаров, который, в свою очередь, перенесен со страницы «Состав».
В процедуру обработки карточек добавлена функция простановки значения группы классификатора 1-торг – заданное значение или значение из группы классификатора карточки складского учета. См. кнопка «Обработать», «Изменение карточки».
В фильтр карточек складского учета на страницу «Склад» добавлен флаг условия отбора «Остатки … не равны нулю».
Если флаг установлен, то на отбор карточек, помимо прочих условий, накладывается условие ненулевых остатков в месте хранения, которое указанно в группе элементов диалога - «Остатки».
Для приходных и расходных накладных создана структура для хранения контрагентов, используемых для печати документов: Поставщик, Грузоотправитель, Грузополучатель, Плательщик.
Контрагенты для печати документов не относятся к содержанию документа и не обязаны соответствовать контрагенту документа. Контрагенты для печати документа задаются и сохраняются в диалоге печати документа. Их сохранение в базе данных служит для целей точного повторного воспроизведения печатных форм документов, как в текущей базе данных, так и в удаленных базах данных.
Контрагенты для печати документов пересылаются по почте вместе с документом.
Внесены изменения в диалог печати. Вместо полей контрагентов печатных форм «От имени», «Грузоотправитель» и «Грузополучатель» введены поля: «Поставщик», «Грузоотправитель», «Плательщик» и «Грузополучатель».
Контрагент «От имени» в приходной накладной получил название «Плательщик», в расходной накладной «Поставщик».
Поля контрагентов для печати заполняются значениями из базы данных, если таковые были ранее сохранены. Если в базе данных контрагенты для печати документа не зафиксированы, то по умолчанию поля заполняются следующим образом:
Для приходной накладной контрагент документа проставляется в поля «Поставщик» и «Грузоотправитель». Локальная настройка «от имени» проставляется в поле «Плательщик». Локальная настройка «Грузополучатель» приходной накладной проставляется в поле «Грузополучатель».
Для расходной накладной контрагент документа проставляется в поля «Плательщик» и «Грузополучатель». Локальная настройка «от имени» проставляется в поле «Поставщик». Локальная настройка «Грузоотправитель» расходной накладной проставляется в поле «Грузоотправитель».
Если контрагент в документе не установлен или локальные настройки не существуют, соответствующие поля останутся незаполненными.
Для управления правами доступа персонала к изменению и печати контрагентов в печатных формах документов в разделы приходных и расходных накладных добавлены по две функциональные роли: «Выбор контрагентов для печати» и «Сохранение контрагентов для печати».
При отсутствии обоих прав оператор может печатать документ только с теми контрагентами, которые определяются при запуске диалога печати.
Право «Выбор контрагентов для печати» позволяет выбрать контрагентов для печати в диалоге и напечатать документ с выбранными контрагентами. Контрагенты при этом в базу данных сохранены не будут и на работу других пользователей не повлияют.
Право «Сохранение контрагентов для печати» позволяет сохранять контрагентов для печати в базу данных для дальнейшего использования этих контрагентов при повторной печати именного этого документа.
Сохранение контрагентов для печати в базу данных будет произведено только в случае установки в диалоге печати флага «Сохранять контрагентов в документе». Если флаг не установлен, внешние контрагенты сохраняются в локальных настройках компьютера.
Для приходной накладной поле «Плательщик» сохраняется в настройку «от имени». Поле «Грузополучатель» сохраняется в локальную настройку раздела приходных накладных «Грузополучатель». Поля «Поставщик» и «Грузоотправитель» не сохраняются.
Для расходной накладной поле «Поставщик» сохраняется в настройку «от имени». Поле «Грузоотправитель» в локальную настройку раздела приходных накладных «Грузоотправитель». Поля «Плательщик» и «Грузополучатель» не сохраняются.
Локальная настройка «от имени» является общей для всех печатных форм и отчетов торговой системы.
В диалог печати документа добавлен флаг «Печать контрагента документа». Установка флага позволяет игнорировать настройки диалога и брать контрагента для печати из контрагента документа. Для приходной накладной это поля «Поставщик» и «Грузоотправитель», для расходной накладной это поля «Плательщик» и «Грузополучатель».
Флаги «Печать контрагента документа» и «Сохранение контрагентов для печати» по умолчанию не установлены. Состояние флагов при закрытии диалога печати не сохраняется и при повторном старте диалога не восстанавливается.
В разделы документов «Заказ поставщику» и «Складское требование» добавлена возможность использовать метки документов и сохранять внешние файлы во вложении к документу. Вложения и метки становятся доступными на странице просмотра и редактирования документа при выборе режима отображения «Вложения и метки» в меню кнопки «Вид».
В раздел документа «Заказ поставщику» добавлена возможность вывода в спецификации документа информационных колонок «Остатки» и «Остатки с подчиненными МХ». Показ колонок включается в диалоге «Информационные поля», который вызывается пунктом меню «Информационные поля …» кнопки «Вид».
Информационные поля служат для информирования о текущих значениях параметра. Эти поля не относятся к документу и не редактируются. Значения в информационных полях соответствуют текущему значению параметра и могут меняться во времени, независимо от изменений самого документа.
В поле «Остатки» показывается значение из колонки «остаток» карточки складского учета для места хранения документа. В поле «Остатки с подчиненными МХ» показывается сумма остатков места хранения документа и всех его подчиненных мест хранения. Значение остатков считывается в момент отображения спецификации документа и не меняется до следующего отображения спецификации, несмотря на то, что текущее значение остатков может быть изменено за счет работы других пользователей.
В спецификацию документа «Контракт на закупку» добавлено поле «Рекомендов. розничная цена» для хранения в документе значений цен, которые должны быть использованы при реализации данного товара по условиям контракта.
Поле заполняется вручную и значение в поле никаким образом не связано пересчетами с другими полями спецификации документа. В текущей версии значение рекомендованной розничной цены не учитывается в процедуре расчета новых цен на основании контракта.
Поле пересылается по почте вместе с документом «Контракт на закупку».
Для поддержания законодательства республики Беларусь в варианте локализации «BY» торговой системы в документы «Контракты на закупку» и «Контракты на реализацию» внесены следующие изменения:
Новые поля пересылаются вместе с документом по почте.
Для варианта локализации «BY» внесены изменения в функции проверки цен приходных накладных на основании контрактов - функция 128 «Проверка на соответствие цен контрактам».
В функцию проверки добавлена проверка соответствия оптовых надбавок от цены производителя, указанной в контракте и в приходной накладной, и изменена логика проверки цен: проверке подвергаются цены производителя в контракте и накладной с учетом диапазона отклонения от эталонной цены, указанного в контракте. Если отклонение от эталонной цены не зафиксировано, то цены не сверяются. Сравнение процентов оптовых надбавок производится всегда, оптовые наценки считаются не совпавшими, если они отличаются друг от друга на величину более 0,01.
В приходной накладной в варианте локализации для республики Беларусь внесены изменения в функцию «Заполнить документ ценами из контрактов». Функция проставляет в накладную ценупроизводителя и оптовую надбавку из подходящего контракта.
Изменено название колонки спецификации «Торговая наценка». Колонка получила название «Оптовая наценка». Такое же изменение внесено в раздел расходных накладных.
Изменено поведение функции автоматического распределения суммы платежа по основаниям. В случае выбора опции – «Увеличить суммы платежей первых неоплаченных документов по списку». В предыдущих версиях суммы обрабатывались от конца списка. В текущей версии суммы обрабатываются, начиная с начала списка документов оснований платежа.
Изменено название колонок таблицы документов оснований платежа. Колонка «Дата док-та поставщика» получила название «Дата док-та торговой системы», колонка «Тип док-та супермага» получила название «Тип док-та торговой системы», колонка «№ док-та супермага» получила название «№ док-та торговой системы».
Изменено название функции проверки 35 «Акт производства обязательно на основании калькуляции». Функция получила название «Акт производства на основании калькуляции».
Внесены изменения в функцию проверки 33 «Корректность документов производства». Из функции удалена проверка соответствия пропорций ингредиентов и готовой продукции в акте производства и калькуляции, на основании которой он был сделан. Проверка пропорций перемещена в функцию проверки 35 в виде детальной части «Пропорция количества не соответствует калькуляции». Прежняя функциональность функции проверки 35 помещена в детальную часть этой же функции «Запрет принятия акта производства не на основании калькуляции».
Перемещение проверки связано со степенью строгости функций. Функция 33 имеет режим «Всегда запрет» и не может быть отменена, ни для какой должности. Функция проверки 35 имеет регулируемые режимы работы.
В драйверы обмена с кассами по протоколам «УКМ2 Стандарт ТХТ» и «УКМ2 Супермаг» внесены изменения для приема из касс информации об обслуженных кредитных картах. Информация принимается из таблицы CASHAUTH. В предыдущих версиях эта таблица не обрабатывалась.
Данные принимаются в структуру торговой системы для хранения чеков, как дополнение к позиции чека. Данные сохраняются в таблицу SMCashAuth вида:
Данные передаются по почте вместе с информацией о чеке в составе Z-отчета. В самой торговой системе данные нигде не отображаются и не используются.
В предыдущих версиях в кассовом модуле момент времени следующей загрузки/выгрузки опеределялся исходя из момента завершения предыдущей загрузки/выгрузки, что со временем давало смещение времени очередной загрузки/выгрузки по отношению к ожидаемому. В текущей версии новый момент времени работы кассового модуля определяется исходя из предыдущего расчетного момента старта прибавлением периода времени загрузки (выгрузки).
В интерфейсе кассового модуля в поле "Прошлая выгрузка" теперь показывается не время окончания последней загрузки/выгрузки, а время старта последней загрузки/выгрузки.
Расширен перечень типов данных для выгрузки в OLAP. К перечню типов данных добавлены типы «Дополнительные характеристики товара», «Штриховые коды», «Кассовые чеки. Платежи (OLAP)», «Кассовые документы. Платежи (OLAP)».
Новые типы данных содержат следующие поля:
Дополнительные характеристики:
Штриховые коды:
Кассовые чеки. Платежи (OLAP):
Кассовые документы. Платежи (OLAP)
В выгрузку типа данных «Карточки товаров» добавлены поля:
Экспорт кредитных карт удален из типа данных "Кассовые чеки (OLAP)" и "Документы (OLAP)". Экспорт дисконтных карт удален из типа данных "Кассовые чеки (OLAP)".
Для почтового обмена в XML формате внесены изменения в формат файла подтверждения почтового приема.
Именование XML пакета подтверждения.
Имя пакета подтверждения имеет следующий вид:
<Имя физического пакета>.Reply.xml
где <Имя физического пакета> - имя файла почтового пакета, для которого создан пакет подтверждения.
Пример: 060403120946_4145_5.Reply.xml
Содержание XML пакета подтверждения.
В случае успешного приема всех объектов почтового пакета с данными, пакет подтверждения содержит только имя почтового пакета:
<REPLY name="Имя физического пакета">
</REPLY>
Пример:
<REPLY name="060403120947_4145_5">
</REPLY>
В случае наличия ошибок приема пакет подтверждения будет иметь следующую структуру:
<REPLY name="Имя физического пакета">
<POSTOBJECT>
<Id>Ключ почтового объекта 1</Id>
<ERROR>Текст сообщения об ошибке обработки объекта</ERROR>
</POSTOBJECT>
<POSTOBJECT>
<Id> Ключ почтового объекта 2</Id>
<ERROR>Текст сообщения об ошибке обработки 1-го уровня вложенности</ERROR>
<ERROR>Текст сообщения об ошибке обработки 1-го уровня вложенности</ERROR>
…..
<ERROR>Текст сообщения об ошибке обработки N-го уровня вложенности</ERROR>
</POSTOBJECT>
<TOTALPACKAGE>
<ERROR>Текст сообщения об ошибке обработки всего пакета</ERROR>
</TOTALPACKAGE>
</REPLY>
Ключ почтового объекта состоит из двухбуквенного кода типа почтового объекта и его идентификатора, например: CDЦ002287 – карточка складского учета Ц002287
Строк с сообщением об ошибке <ERROR> может быть несколько в тех случаях, когда имеется несколько источников сообщения об ошибке приема разного уровня вложенности.
Сообщение об ошибке <TOTALPACKAGE> может присутствовать в том случае, если ошибка произошла не при обработке объектов, а при обработке самого почтового файла, например, файл не смог быть прочитан.
Количество и состав ошибок может быть произвольный, то есть могут присутствовать или отсутствовать как сегменты <POSTOBJECT>, так и <TOTALPACKAGE>
Пример:
<REPLY name="060403120946_4145_5">
<POSTOBJECT>
<Id>CDЦ002287</Id>
<ERROR>Текст сообщения об ошибке обработки объекта CD Ц002287</ERROR>
</POSTOBJECT>
<POSTOBJECT>
<Id>WI00002</Id>
<ERROR>Текст сообщения об ошибке обработки объекта WI 00002</ERROR>
<ERROR>Причина предыдущей ошибки обработки объекта WI 00002</ERROR>
</POSTOBJECT>
<TOTALPACKAGE>
<ERROR>Текст сообщения об ошибке обработки всего пакета</ERROR>
</TOTALPACKAGE>
</REPLY>
Изменения функционала в версии 1.024.5 сервис пак 4.
Национальные шрифты для короткого названия товара.
Загрузка в кассу полного названия товара.
Для ввода и отображения короткого названия товара шрифтами, содержащими необходимые символы национального языка, реализовано управление шрифтом элемента диалога с коротким названием товара.
Короткое название товара используется для передачи названия товара в кассы, весы, терминалы сбора данных, а также для печати этикеток и ценников. То есть для отображения названия товара покупателю.
Шрифт для короткого названия товара и его атрибуты – размер, язык и т.д., задаются в административном модуле в разделе «База данных» в группе данных «Клиентская часть».
Там же задаются параметры перекодировки при передаче текста короткого названия в кассовую программу УКМ2. В прежних версиях программы перекодировка текстов происходила с использованием установки операционной системы: Страна расположения системы. То есть в случае использования страны Россия перекодировка осуществлялась из кодовой страницы Windows 1251 в DOS 866.
В текущей версии можно задать иные кодовые страницы, в зависимости от требуемого языка. При настройке шрифта и кодовых страниц для перекодировки, необходимо учитывать, что язык шрифта выбирается в стандартном диалоге выбора шрифта и не влияет на процедуру перекодировки. Язык шрифта влияет только на отображение текста в разделе карточек складского учета в элементе диалога «Короткое название». Для правильного поведения программы загрузки данных в кассу необходимо дополнительно правильно настроить кодовую страницу Windows и кодовую страницу DOS в диалоге административного модуля.
Настройки шрифта и кодовых страниц влияют на передачу в кассу только названия товара. Прочие тексты, например, названия единиц измерения, групп классификатора и т.д. передается прежним образом, поскольку в торговой системе эти тексты могут быть отображены только в одной кодовой странице и только одним шрифтом.
Необходимо учитывать, что настройка шрифтов Windows для отображения короткого названия товара в интерфейсе торговой системы не может отразиться на наличие или отсутствие таких шрифтов в устройствах, с которыми ведется обмен данными. Также как и для печати ценников с использованием национальных шрифтов требуется отдельное создание таких ценников.
Для частных потребностей проекта АДА реализована опциональная загрузка в кассу полного или короткого названия товара.
Управление опцией осуществляется через таблицу системных настроек. Для выгрузки только полного названия товара в таблицу должен быть добавлен параметр CashLoadFullName со значением 1.
При отсутствии параметра или при значении параметра 0, в кассу будет передаваться название товара по прежним правилам, то есть короткое название товара или полное название, если короткое отсутствует.
При загрузке в кассу полного названия товара название товара будет подвергаться перекодировке по тем же правилам, что и короткое название товара. См. пункт «Национальные шрифты для короткого названия товара».
Для режима инвентаризации кассы загрузка только полного названия товара не предусмотрена.Изменения функционала в версии 1.024.6
Документ «Заказ поставщику». Время поставки.
Документ «Заказ от клиента».
Документ «Акт переоценки».
Редактирование документов, отосланных на корректировку.
Фильтр отбора документов по перечню мест хранения.
Опция отчетов выбора мест хранения или группы мест хранения.
Операция в мастере создания документа.
Место хранения склада в складском требовании.
Выбор перечня мест хранения при генерации складских требований.
Отображение суммы НДС в документах.
Функция накладных «Проставить страну из карточек».
Функция приходных накладных «Заполнение отрицательными остатками».
Функция расходных накладных «Заполнение положительными остатками».
Контроль номенклатуры места хранения в документах.
История вхождения артикула в состав номенклатуры.
Загрузка ТСД с ограничением по номенклатурам артикулов.
Название разделов для контрактов.
Отчет «Реализация товаров». Опция «Только номенклатуры мест хранения».
Отчет «Доходность по товарам». Опция «Группировать по местам хранения».
Отчет «Исполнение заказов». Опция «Показывать суммы».
Отчет «Товар без движения».
Печать документа «Заказ поставщику». Опция «Показывать упаковки».
Программа генерации и модернизации схемы базы данных.
В заголовок документа «Заказ поставщику» добавлено поле «Время поставки». Поле доступно для редактирования для документов со статусом «Черновик». Новый атрибут документа имеет информационный характер и предназначен для регистрации желаемого времени доставки товара в торговую организацию.
Время поставки выводится в печатной форме документа.
В торговую систему добавлен новый раздел «Заказы от клиентов». Раздел предназначен для регистрации документов заказа товаров и услуг, поступивших со стороны клиентов.
Функционально раздел совпадает с разделом «Заказ поставщику» с учетом того, что заказ делается не поставщику на поставку товара в торговую организацию, а от клиента на покупку товара в торговой организации. Атрибуты документов одинаковы.
Функциональные различия между документами следующие:
Изменение статуса документа «Заказ от клиента» не влияет на состояние таблицы остатков, в отличие от документа «Заказ поставщику», который влияет на количество товара ожидаемого к поставке. В случае заказа от клиента резервирование товара осуществляется документом «Счет», а заказ от клиента является только декларативным документом.
При отгрузке товара клиенту на основании заказа контроль соответствия количества и цен заказа и отгрузки не осуществляется.
Поле «Затребованное количество», аналогичное полю «Предложение заказа», доступно для редактирования и имеет смысл – количество товара, первоначально затребованное клиентом. Конечное значение количества заказа в документе может быть скорректировано с учетом возможностей текущих запасов и может не отражать фактическое желание клиента. Сохранение исходного требования клиента является необязательным и может быть полезно только в случае использования этой информации в маркетинговых целях.
Поле «Артикул клиента», аналогичное полю «Артикул поставщика», имеет ценность в случае, если преследуется цель получать заказ от организаций в терминах клиента.
Раздел «Акты переоценки» подвергся внутренней реорганизации. Реорганизация не привела к изменению функционального назначения раздела. В интерфейс и поведение раздела внесены следующие изменения:
Режим отобранных документов.
В режиме отобранных документов в диалог настройки полей – «Поля таблиц документов» добавлена страница для управления составом полей спецификации документа.
Заголовок документа.
В интерфейс заголовка документа добавлены атрибуты:
Наценивать от полной цены.
Атрибут «Наценивать от полной цены» определяет алгоритм расчета новой цены при наценивании и необходим при анализе результатов наценивания. Значение атрибута проставляется по значению такого же атрибута места хранения в момент создания документа. Атрибут можно редактировать, если есть необходимость при ручном расчете наценки использовать иной алгоритм наценивания, чем заданный для места хранения. В случае генерации акта переоценки на основании контракта значение атрибута устанавливается соответственно значению атрибута контракта «Цена контракта» (с НДС / без НДС).
Налоги вида цены.
Атрибут «Налоги вида цены» является информационным, то есть в документе не хранится, и показывается по текущему состоянию атрибутов вида цены из заголовка документа. Состав налогов в виде цене необходим при анализе результатов наценивания, в формуле расчета которых участвуют налоги.
Если акт переоценки создан не для расчета новой цены на основании цены поступления (прихода) товара, то атрибуты «Наценивать от полной цены» и «Налоги вида цены» значения не имеют.
Время исполнения.
Поле «Время исполнения» показывает дату и время фактического исполнения акта переоценки. Данное поле присутствовало в структуре документа ранее, но не отображалось. После модернизации версии продукта в поле «Время исполнения» будет показываться истинное время исполнения всех ранее созданных и исполненных актов переоценки.
Поле «Дата исполнения» получило название «Ожидаемая дата исполнения».
Спецификация документа.
Наценка и переоценка.
Поле «Наценка/Переоценка» разделено на два поля, которые показываются независимо от того, в ходе какого процесса был создан документ. Поле «Переоценка» заполняется всегда на основании информации о старой и новой цене артикула. Содержание поля «Наценка» зависит от способа создания акта переоценки. Если в основании акта переоценки отсутствует приходная накладная или иной документ поступления товара, то поле «Наценка» остается незаполненным. Если документ поступления товара имеется, то в поле помещается процент наценки, рассчитанный на основании цены документа основания акта, состава налогов вида цены и метода расчета наценки.
Оба поля редактируются, но значение процента переоценки или наценки, введенное пользователем, в документе не сохраняется, а используется только для расчета нового значения цены. Новое значение цены всегда округляется до точности валюты, что может приводить к изменению введенного значения процента наценки или переоценки на величину, эквивалентную точности округления цены.
Налоги.
В спецификацию добавлено поле «Налоги». Поле содержит значение ставок налогов, которые относятся к артикулу из строки спецификации. Значения ставок налогов для артикула используются для расчета значения поля «Наценка».
Значение ставок налогов артикула проставляется в момент заполнения спецификации значениями ставок, действующих на дату документа. При дальнейшей работе с документом эти величины не изменяются. При модернизации схемы базы данных значения ставок не заполняются. Для ручного обновления значений ставок создана функция «Обновить налоги». Функция доступна, в том числе, для документов со статусом «Исполнен», поскольку результат работы функции влияет на статистические данные – значения ставок налогов, действующих на дату документа. Эти данные необходимы для эффективной работы интерфейса документа при расчете значения поля «Наценка» и не влияют на функции документа.
Поле «Цена без налогов» - удалено.
Цена прихода полная и цена прихода без налогов.
Поле «Цена прихода (без налога)/Цена прихода» разделено на два поля «Цена основания без налогов» и «Цена основания полная». Поля информационные и показывают цены из позиций спецификации документа основания для наценивания с таким же артикулом. В случае отсутствия документа основания поля не заполняются. В случае если документ основания для наценивания содержит только одну цену, оба поля заполняются одинаковым значением. Смысл цены в этом случае определяется типом документа основания. Если документ основания – выход из производства или акт сортировки, то цена документа основания - это цена без налога, и цена полная равна цене без налога из-за того, что в операциях, которые отражаются этими документами, налогов нет. Если документ основания – контракт, то тип цены основания зависит от вида цены контракта – цена с НДС / без НДС. Вид цены контракта при создании акта переоценки на основании контракта отражается на значении флага акта переоценки «наценивать от полной цены».
Акт ордера цен (Ордер исполнен).
В текущей версии поле флага «Ордер исполнен» заменено полем «Акт ордера цен», в котором отображается номер акта переоценки, созданный на основании строки спецификации ордера цен. В предыдущей версии аналогичное поле было виртуальным и показывало факт наличия актов переоценки, созданных на основании ордера цен. В текущей версии это поле добавлено в спецификацию документа и заполняется номерами актов переоценки при их исполнении. Как следствие поведение интерфейса и документа претерпело некоторые изменения. Теперь, при удалении акта переоценки, ссылка на него не теряется, и создать новый акт переоценки по тому же ордеру цен невозможно. Управление отображением поля «Акт ордера цен» в спецификации сделано явным. См. «Информационные поля», тогда как в предыдущей версии оно отображалось только для документов с признаком исполнения – Ордер цен.
Информационные поля.
Расширен перечень информационных полей, то есть расчетных полей, которые оператор может включать или исключать из просмотра таблицы спецификации документа:
Поле «Налоги» тоже относится к информационным полям, но прямого управления этим полем не предоставляется. Поле «Налоги» показывается или скрывается только вместе с полем «Наценка».
Управление информационными полями позволяет управлять производительностью отображения спецификации при открытии или редактировании документа.
Функции.
Вызов функций обновления значений в информационных полях спецификации перенесен в пункты меню «Функция»:
Кнопки вызова этих функций убраны из интерфейса заголовка документа.
Название функция «Округлить цены» заменено названием «Применить правила округления».
Поведение документа при редактировании.
В предыдущей версии поддерживалось автоматическое пополнение спецификации документа составными артикулами при добавлении в спецификацию их базовых артикулов. В текущей версии автоматическая коррекция спецификации отменена. Вместо этого в интерфейс добавлены функции:
Вызов функций помещен в меню кнопки «Доп. команды».
Одновременно удалена функция проверки 139 «Запрет наценивания компонент набора при неопределённых ценах на другие компоненты» с режимом «Всегда запрет», которая контролировала обязательное наличие полного набора базовых артикулов для составных артикулов акта в спецификации акта переоценки.
Для контроля полноты или неполноты состава спецификации акта переоценки для составных артикулов и их базовых артикулов созданы новые функции проверки:
В текущей версии разрешается вести раздельную переоценку базовых артикулов и созданных на их основе составных артикулов, или запрещать такого рода ценообразование в зависимости от правил, принятых в организации.
В предыдущей версии поддерживалась автоматическая коррекция процента переоценки и процента наценки в тех случаях, когда он выходил за пределы минимального или максимального разрешенного значения. В текущей версии автоматическая коррекция заменена функцией проверки:
Для общего контроля корректности документов Акт переоценки добавлена функция проверки:
Функция проверяет следующие условия:
Изменена функция проверки 120 «Корректность документов "Акты переоценки"» с режимом «Всегда запрет». Функция получила название «Проверки при принятии акта переоценки в ручном режиме» и управление режимами по должностям. Режим по умолчанию - «Предупреждение». Из функции удален контроль перевода документ типа «Ордер цен» в запрещенные для него статусы «Принят к исполнению» и «Исполнен». Запрет на перевод ордера цен в эти статусы реализован на уровне процедур смены статуса. В функции сохранена проверка соответствия вида цены акта переоценки и места хранения акта переоценки.
Внесены изменения в диалог печати документа. Из диалога убраны опции печати акта переоценки в базовой валюте и в валюте вида цены. Акт переоценки печатается только в валюте вида цены.
Для управления правами доступа персонала к редактированию документов, отосланных на корректировку, в разделы приходных накладных, расходных накладных и накладных на перемещение добавлены новые функциональные права «Редактирование документов, требующих корректировки».
Для документов с признаком «требует корректировки» новое функциональное право замещает регулярные права редактирования документа и действует на документы со статусом «Черновик» и «Принят складом». То есть наличие права редактирования документа не позволяет редактировать документ, требующий корректировки, также как наличие права редактирование документа требующего корректировки не позволяет редактировать документ без признака «Требует корректировки».
Для повышения статуса документа, требующего корректировки, необходимы те же права доступа, что и для документов без этого признака. При ограничении прав доступа персонала к функциям работы с документами по критерию: срок давности от даты документа, необходимо учитывать, что функции поднятия статуса должны иметь такое же ограничение по сроку давности, что и функции редактирования документа с признаком «Требует корректировки».
Необходимо учитывать, что признак «Требует корректировки» автоматически снимается при любом повышении статуса документа, требующего корректировки, после чего вступают в силу права, относящиеся к документам без признака «Требует корректировки».
Во всех разделах документов, в которых имеется отбор по месту хранения, в интерфейсе подробного фильтра изменен элемент диалога для выбора места хранения. Новый элемент диалога позволяет использовать классификатор мест хранения для отбора перечня мест хранения в окно просмотра и позволяет указать перечень мест хранения вместо одного места хранения для отбора документов.
Элемент диалога для краткого фильтра остался прежним.
В перечисленных ниже отчетах в диалоге старта отчета опция выбора места хранения (Все, только одно выбранное) заменена опцией выбора места хранения (Все, группа …, только …) с возможностью указания группы мест хранения или перечня мест хранения.
При модернизации версии схемы базы данных режим использования проверок устанавливается в значение по умолчанию – «Предупреждение».
В раздел карточек складского учета в окно детальных свойств артикула добавлена страница «История номенклатур». В журнале истории номенклатур отображается время добавления или удаления артикула в номенклатуру, код и название номенклатуры, и атрибуты сотрудника, совершившего действие.
История вхождения артикулов в номенклатуру ведется, начиная с данной версии. Все предшествующие действия в журнале отсутствуют.
В разделе «Портативный терминал» расширен перечень условий отбора артикулов при формировании списка артикулов для загрузки в терминал сбора данных.
В перечень добавлены условия:
Перечень номенклатур может создаваться ручным выбором номенклатуры из списка или указанием места хранения, номенклатуры которого необходимо использовать для ограничения списка артикулов, загружаемых в терминал сбора данных.
Раздел документов «Контракты на закупку» получил название «Контракты с поставщиками», раздел «Контракты на реализацию» получил название «Контракты с клиентами».
Переименование произведено для совместимости с названиями разделов заказов. С этой же целью изменены цветовые маркеры иконок для разделов заказов, чтобы объединить документы Контракт – Заказ – Поставка в группы документов, относящихся к процессам приобретения и процессам реализации.
В диалог старта отчета «Реализация товаров» добавлена опция «Только номенклатуры мест хранения».
При выборе одного места хранения для старта отчета опция «Только номенклатуры мест хранения» ограничивает перечень артикулов отчета списком номенклатур, выбранного места хранения.
При выборе нескольких мест хранения опция ограничивает перечень артикулов общим списком номенклатур всех выбранных мест хранения. Если в список попадет хотя бы одно место хранения, для которого нет ни одной номенклатуры, то в отчете список артикулов не будет ограничиваться какими-либо номенклатурами.
В диалог старта отчета «Доходность по товарам» добавлена опция «Группировать по местам хранения».
При выборе опции данные отчета группируются по местам хранения. По каждому месту хранения подводится итог.
При выполнении отчета с группировкой по местам хранения доля в доходе рассчитывается относительно данных места хранения. Также относительно данных места хранения делается отбор артикулов с наибольшими и наименьшими показателями.
В диалог старта отчета «Исполнение заказов» добавлена опция «Показывать суммы». Опция доступна только при выбранной опции «Заказы с поставками недопоставленного товара».
Товар считается недопоставленным, если совокупное количество товара в приходных накладных на основании заказа меньше количества в заказе. В расчет принимаются только полностью оприходованные приходные накладные.
При выборе опции «Показывать суммы» в отчете выводится колонка «Сумма недопоставленного товара». Сумма выводится в ценах заказа.
Если дополнительно выбрать опцию «Показывать товары» в отчете выводится колонка «Цена заказа».
В диалог старта отчет добавлены следующие опции:
Опции позволяют ограничить вывод данных в отчете по количеству текущих остатков и упорядочить вывод строк в отчете внутри групп товаров по убыванию количества.
В диалог старта печати документа «Заказ поставщику» добавлена опция «Показывать упаковки».
При отключении опции в печатной форме не показываются колонки «Упаковка поставщика» и «Кол-во упаковок».
В программе генерации схемы базы данных изменен способ хранения скриптов, необходимых для работы программы.
Функциональность программы осталась без изменения. Изменения проявляются только во внешнем виде процесса работы программы. Теперь непосредственно перед исполнением скриптов выполняется их распаковка из архива.Изменения функционала в версии 1.024.6 сервис пак 1.
Отчет "Остатки". Опция "группировать по налоговым группам".
Отчет "Реестр накладных".
Опция "Метки документов".
Опции "Накладные на перемещение (приход)" и "Накладные на перемещение (расход)".
В отчет «Остатки», группа «Товарные», добавлен флаг «группировать по налоговым группам». Флаг может быть установлен только при выводе отчета с ценами.
При установленном флаге данные отчета выводятся с группировкой артикулов по принадлежности их налоговым группам региона, выбранного места хранения или региона «Наш регион», если выбраны все места хранения.
В качестве названия налоговой группы выводится не название группы, а перечень налогов и их ставок, входящих в состав налоговой группы.
Группировка по налоговым группам делается внутри мест хранения. Группировка по группам товаров делается внутри каждой налоговой группы, если в диалоге старта указана группировка по группам товаров. Итоги подводятся по каждой налоговой группе отдельно. Совокупные итоги по налоговым группам выводятся в конце отчета.
Внесены изменения в опции отчета «Реестр накладных», группа «Документооборот».
В отчет добавлена опция выбора меток документов для отбора только документов с метками.
Опция имеет варианты выбора «Все» и «Только…». При выборе варианта «Все», отчет выполняется без ограничения отбора документов по наличию или отсутствию в них меток.
При выборе варианта «Только…» выводится диалог для выбора метки и указания метода отбора документов:
Опция «не назначена документу», означает, что в документе отсутствует какое-либо значение метки.
Опция «назначена документу» означает, что в документе имеется какое-либо значение метки.
Опция «назначена документу и имеет значение …» позволяет указать значение метки, по которому будут отбираться документы.
Значение метки можно выбрать из списка значений, зафиксированных в справочнике меток документов или можно ввести произвольный текст. Если метка имеет тип «дата» и не имеет перечня заранее заданных значения, то произвольное значение метки должно быт введено в виде: «YYYYMMDD HH24:MI:SS».
Опция "накладные на перемещение" заменена двумя опциями "накладные на перемещение ИЗ", "накладные на перемещение В".
Разбиение опции на две позволяет отдельно управлять в отчете отбором как накладных на перемещение на приход товара в место хранения, так и на расход товара.Изменения функционала в версии 1.024.6 сервис пак 2.
Выгрузка данных о товарах в кассы. Частичная выгрузка скидок на количество.
Отчет «Сравнение прайс-листов».
Отчет «Список товаров с коротким штриховым кодом». Опции отчета.
Внесены изменения в алгоритм частичной выгрузки данных о товарах. В предыдущих версиях артикул считался измененным и попадал в список артикулов инкрементальной выгрузки, если был изменен собственно артикул, или его цена, или его штриховой код. В текущей версии в условие, по которому артикул считается измененным, добавлено условие – изменена скидка на количество для артикула.
Изменение скидки на количество при инкрементальной загрузке проверяется только для вида цены для кассы.
Создан новый отчет «Сравнение прайс-листов». Отчет размещен в группе «Справочные данные».
Отчет предназначен для сравнения цен артикулов по разным видам цен одного и того же места хранения.
Отчет может быть использован для контроля ценообразования в том месте хранения, в котором производится расчет и установление новых цен.
Отчет предназначен, прежде всего, для печати перечня артикулов, на которые не нанесены штриховые коды и которые идентифицируются на кассе по их числовому коду, то есть по коду типа «короткий штриховой код».
В отчет «Список товаров с коротким штриховым кодом» добавлены две опции:
Опция «только артикулы для кассы» позволяет ограничивать в отчете список артикулов по тем же правилам, что и при загрузке в кассу: в отчет будут попадать только активные артикулы с признаком «грузить в кассу» и с ненулевой ценой для кассы.
Опция «показывать поле «Артикул»» позволяет скрыть поле артикул при выводе отчета, чтобы кассир не допускал ошибок при вводе кода товара и не пытался ввести вместо кода товара его артикул.Изменения функционала в версии 1.024.6 сервис пак 4.
Загрузка названий ингредиентов в весы Digi Ethernet.
Функция проверки 12 «Документ содержит товары с нулевой ценой».
Белоруссия. Признак «Гос.регулирование» для расходных накладных.
Под названием ингредиентов понимается список названий материалов, из которых состоит товар и который необходимо печатать на этикетках или ценниках или иных сопроводительных документах в качестве информации для покупателей. Название ингредиентов товара для весов задается в разделе карточек складского учета на странице «Описание» в характеристике «Состав». Название каждого ингредиента должно задаваться в новой строке описания состава товара.
При печати этикеток на весах Digi, в тех случаях, когда длина названия ингредиента товара или высота строк названий ингредиентов превышает размеры соответствующего поля в этикетке весов, весы название ингредиентов не печатают.
В алгоритм формирования файла данных с названием ингредиентов для весов Digi внесено изменение для ограничения длины названия ингредиента и количества строк названий при передаче их в весы.
Ограничение задается в количестве строк и количестве символов в строке, которое может поместиться в поле для названий ингредиентов. Ограничение устанавливается в разделе Настройка->Настройка аппаратуры->Электронные весы на странице «Этикетка» для весов типа Digi Ethernet.
По умолчанию ограничение не установлено. При установке ограничения можно воспользоваться стандартным значением, которое рассчитано для поля шириной 56 мм и шрифта S2. Количество строк по умолчанию устанавливается равным 2. Фактическое количество строк зависит от высоты поля ингредиентов и должно подбираться опытным путем.
При использовании этикеток с шириною менее 58 мм или при ширине поля для названий ингредиентов менее 56 мм необходимо опытным путем определять количество символов в строке.
Настройки для ограничения длины названия ингредиентов и количества строк ингредиентов должны задаваться для каждого экземпляра весов отдельно.
Внесены следующие изменения в поведение функции проверки 12 «Документ содержит товары с нулевой ценой».
1. Для актов переоценки контроль цен в спецификации документа теперь будет осуществляться при переходе со статуса «Черновик» на статус «Принят к исполнению», а не со статуса «Принят к исполнению на «Исполнен», как это было ранее. Также отменена специальная проверка для ордера цен, при смене статуса на «Заблокирован». Изменение внесено в связи с тем, что в отличие от других проверяемых документов, цены в акте переоценке окончательно фиксируются на статусе «Принят к исполнению» и дальше меняться не могут.
2. Функция проверки 12 получила детализацию по типам документов, что позволяет назначать должности разные режимы работы проверки для разных типов документов.
В мастер создания расходной накладной добавлена страница «Государственное регулирование» для отнесения отпускаемого товара к необходимому типу государственного регулирования цен. При выборе типа государственного регулирования цен товара «Фиксированная гос. цена» в документ, при создании, добавляется не удаляемая системная метка «Гос. регулирование» со значением «Гос. цена». Наличие данной метки в документе приводит к изменению алгоритма автоматического пересчета сумм и цен в спецификации накладной в соответствии с требованием законодательства.Изменения функционала в версии 1.025
Собственные контрагенты.
История изменения объектов системы.
История документов, сумма документа.
История удаления документов.
История контрагентов.
История удаления контрагентов.
История удаления карточек складского учета.
История изменения пароля пользователя Супермага.
Акт переоценки. Информационное поле «Бух. Остатки».
Акт переоценки. Заполнение документа продажными ценами.
Инициализация вида цены.
Изменение формата ввода ГТД.
Контроль ставок НДС в накладных.
Цена для кассы в документах производства и накладной на перемещение.
Замещение накопительных дисконтных карт.
Проверка контрольного разряда штрихового кода EAN 13.
Контроль версии объекта при почтовом приеме.
Контроль последовательности исполнения актов переоценки.
Печать этикеток с ценой из накладных на перемещение.
Интерфейс управления почтовым модулем.
Состав почтового модуля.
Интерфейс администратора почтового модуля.
Выбор службы почтового модуля.
Управление службой почтового модуля.
Регистрация баз данных.
Настройки Почтового модуля для работы с базой данных.
Управление почтовым обменом.
Расписание полной принудительной загрузки касс.
Сообщения кассового драйвера УКМ2.
Драйвер касс УКМ4.
Трассировка расчета товародвижения.
Управление стандартным диалогом старта пользовательских отчетов.
Автоматическая установка клиентской части с правами администратора.
Изменение системы лицензионной защиты.
В разделе Контрагенты добавлена страница «Собств. контрагент», на которой имеется флажок «собственный контрагент» и возможность задать перечень мест хранения, которые обслуживаются данным контрагентом.
Под собственным контрагентом понимается такой контрагент, который не является независимым внешним поставщиком или покупателем. Это может быть юридическое лицо в составе холдинга или контрагент, с которым имеются особые отношения. Понятие собственного контрагента не совпадает с понятием «Партнер», которое используется для поддержания корректного, с точки зрения бухгалтерии, документооборота юридических лиц и для расчета себестоимости движения товара по партнерам с разными методиками списания. Партнер в системе может обмениваться товарами с другими юридическими лицами – партнерами только посредством купли-продажи товара. Партнер обязан владеть местом хранения только типа центральный склад. Все места хранения, подчиненные центральному складу, автоматически принадлежат партнеру. Эти условия позволяют однозначно и корректно рассчитывать бухгалтерскую себестоимость по партнерам, но не позволяют получить сводную себестоимость движения товара при его движении через несколько партнеров к покупателю.
Понятие собственного контрагента может быть использовано для описания структуры холдинговой компании в тех случаях, когда управленческие задачи отделены от задач бухгалтерского учета. То есть когда для целей бухгалтерского учета достаточно корректного отнесения документов к тем или иным юридическим лицам, тогда как себестоимость и движение товара должно соответствовать интересам управленческого учета и отражать данные для холдинга, а не для отдельного юридического лица. Собственный контрагент может быть связан с одним или несколькими местами хранения, либо не связан ни с одним местом хранения.
В текущей версии системы понятие собственного контрагента в бизнес-процессах или отчетах не используется. В последующих версиях понятие собственного контрагента предполагается использовать для диверсификации бизнес-процессов приема и отпуска товара.
В таблицу журнала изменения документов добавлено поле «Сумма». В поле сохраняется значение полной суммы документа на момент регистрации записи в журнале, то есть новое значение суммы.
При анализе журнала истории документов необходимо учитывать, что в журнале фиксируются только факты создания, удаления и изменения статуса документа. Все изменения документа между изменениями статуса не регистрируются.
Для тех типов документов, у которых поле «Сумма» в заголовке документа отсутствует, например, для актов потерь, поле «Сумма» в журнале истории документа не сохраняется и не показывается.
Для всей предыдущей истории документов, образовавшейся при работе с документами в прошлых версиях торговой системы, значение сумм будет отсутствовать и в журнале будет представлено пустым значением.
Во всех разделах документов в меню «Функции» добавлен пункт «Журнал удаленных документов».
Функция позволяет получить информацию о дате, времени и номерах удаленных документов, соответствующих типу документов раздела, а также посмотреть историю удаленных документов.
Окно диалога «Журнал удаленных документов» состоит из двух частей. Верхняя часть - история удаления документов - содержит список фактов удаления документов в порядке убывания даты-времени удаления. Нижняя часть содержит историю для документа, отмеченного в верхней части окна.
Один и тот же документ будет показан в таблице истории удаления документов столько раз, сколько раз он удалялся. Такое может случиться, если после удаления документа создается новый документ с тем же номером, что и у удаленного документа, а затем он удаляется повторно.
Для контрагентов создан журнал истории контрагентов. Для отображения журнала в разделе «Контрагенты» создана страница «Журнал».
Журнал истории изменения контрагентов имеет два варианта – сокращенный и расширенный, так же как и журнал истории изменения артикулов. Управление вариантом ведения журнала осуществляется в административном модуле в разделе «База данных» на странице «Конфигурация» в группе данных «Прочие». Для включения режима ведения расширенного журнала необходимо установить флаг «Расширенный формат журнала контрагентов».
Так же, как и для журнала карточек складского учета, смена режима ведения журнала с краткого на расширенный не приводит к восстановлению истории предыдущего периода. Смена режима приводит к расширению или, соответственно, к сокращению объема информации, которая регистрируется в журнале, начиная с момента смены режима.
В кратком режиме ведения истории изменений в журнале регистрируется дата, время и вид изменения (операция) записи о контрагенте, а также информация о сотруднике, совершившем изменение.
В расширенном режиме дополнительно сохраняется информация о том какой атрибут был изменен и новое значение атрибута записи контрагента. Запись о контрагенте считается измененной, если измен один из атрибутов основной записи. Все атрибуты раздела «Контрагенты», которые могут иметь много значений для одного контрагента, не относятся к основной записи и их изменение не приводит к регистрации факта изменения контрагента в истории, например, перечень складов или сотрудников контрагента.
В меню «Функции» раздела «Контрагенты» добавлен пункт меню «Журнал удаленных контрагентов».
Диалог истории удаленных контрагентов имеет такой же вид и функциональность, что и журнал истории удаленных документов. Перечень полей с информацией об удаленном объекте включает идентификатор контрагента и название контрагента на момент его удаления.
В меню «Функции» раздела «Карточки складского учета» добавлен пункт меню «Журнал удаленных карточек».
Диалог истории удаленных карточек имеет такой же вид и функциональность, что и журнал истории удаленных документов. Перечень полей с информацией об удаленном объекте включает название карточки складского учета и единицу измерения карточки на момент ее удаления. Эта информация, начиная с текущей версии, сохраняется в журнале изменений карточки независимо от выбранного режима ведения журнала.
В предыдущих версиях удаление карточки приводило к удалению всей истории изменения карточки, соответственно, после установки текущей версии история ранее удаленных карточек показываться не будет. Будет показываться только история тех удалений, которые будут совершены после установки текущей версии.
В административном модуле в разделе «Права доступа» на странице «Сотрудники» имеется доступ к журналу истории действий с учетной записью сотрудника – пользователя системы.
В журнал истории операций с пользователем системы добавлена регистрация операции смены пароля – «Смена пароля». Внешний вид таблицы журнала остался без изменений.
Все предыдущие операции смена пароля, произошедшие до установки текущей версии системы, в журнале не зарегистрированы, и показываться не будут.
В документ Акт переоценки добавлено два информационных поля – «Бух. остатки» и «Бух. остатки с подчиненными м.х.». В этих полях показываются остатки по полностью зарегистрированным товарным документам, в отличие от полей «Остатки» и «Остатки с подч. м.х.», в которых показываются складские остатки, то есть, включая остатки по не полностью обработанным документам - в статусе принят/отпущен складом. При анализе значений этих полей необходимо учитывать, что отрицательные значения количества при переоценки принимаются равными нулю.
В раздел «Акт переоценки» добавлена функция «Заполнить документ продажными ценами».
Функция позволяет заполнить поле «Цена» спецификации документа значениями цен выбранного вида цены для указанного места хранения.
Интерфейс старта функции ограничивает выбор цен только активными видами цен для указанного места хранения. По умолчанию, в интерфейсе выводится место хранение и вид цены документа «Акт переоценки».
В разделе «Цены» на странице «Виды цен» имеется вызов функции «Инициализация вида цены». В предыдущих версиях функция позволяла рассчитать цены для нового вида цены на основании цен последних приходов товаров и правил наценивания, установленных для этого вида цены, и помещала рассчитанные цены в специально созданный акт переоценки для нового вида цены.
В текущей версии к прежнему варианту расчета цен для нового вида цен добавлен еще один – простановка цен из другого вида цены и добавлена функция копирования наценок из другого вида цены. Новый вариант инициализации вида цены позволяет выполнить задачу копирования цен одного магазина в другой магазин, например, при открытии нового магазина.
В диалог старта функции добавлен выбор одной из трех доступных функций: функции генерации акта переоценки на основании цен последних приходов, генерация акта переоценки путем простановки цен из другого вида цены и функции копирования наценок.
При переносе цен из другого вида цены с иной валютой, цены копируются без учета курсов валют, но с учетом точности валюты нового вида цены.
Функция копирования наценок из одного вида цены в другой вид цены не отменяет уже установленные наценки нового вида цены, если они установлены для такой группы классификатора, которая не имеет персонального значения наценки в исходном виде цены. При копировании наценок необходимо помнить, что значения наценок будут установлены немедленно, в ходе работы процедуры, в отличие от цен, которые помещаются в акт переоценки со статусом «Черновик».
В предыдущих версиях торговой системы считалось, что длина кода таможенного органа в номере справки к ГТД составляет 5 символов. В приходных, расходных накладных и накладных на перемещение элемент диалога для ввода номера справки к ГТД состоит из трех частей. При вводе номера справки курсор автоматически перемещается к следующему элементу после ввода необходимого числа символов. В текущей версии число символов, после которого курсор переходит с кода таможенного органа на дату справки к ГТД увеличено до восьми.
Такое же изменение внесено в функцию проверки корректности введенного номера справки к ГТД.
Для документов «Приходная накладная», «Расходная накладная», «Счет», «Счет-фактура кассового чека» создана функция проверки 160 «Несовпадение ставок НДС в документе и в карточке товара». По умолчанию функция имеет режим «Предупреждение».
Режим использования функции устанавливается одинаковым для всех перечисленных типов документов.
Функция осуществляет проверку соответствия значений ставок НДС, зафиксированных в спецификации документа, и значений ставок НДС, описанных в истории действия налоговых групп для артикула спецификации. Значение ставки НДС для артикула определяется на дату документа. Проверка осуществляется при переводе документа из статуса Принят складом / Отпущен складом / Выставлен до Принят полностью / Отпущен полностью / Закрыт / Принят, соответственно.
В спецификацию документов производства «Расход в производство», «Выход из производства», «Возврат из производства» добавлено информационное поле «цена для кассы». Поле «Цена для кассы» заполняется текущим значением цены для кассы места хранения документа в момент смены статуса документа на «полностью принят» по тем же правилам, что и для приходных и расходных накладных.
Функция заполнения поля «Цена для кассы» включается в административном модуле в разделе «Базы данных» в группе данных «Ценообразование», флагом «Проставлять цену для кассы в накладные».
В накладных на перемещение в таблицу статистики SMSpecStat добавлены поля для сохранения времени регистрации и значения цены для кассы места хранения «Из». Цена для кассы места хранения «Из» сохраняется в документе при смене статуса с «Черновик» на «Отправлен». В интерфейсе данное значение не отображается, но может быть использовано в отчетах.
Изменения внесены для обеспечения бизнес-процесса учета товара в ценах реализации.
В разделе «Скидки» на странице «Дисконтные карты» создана процедура замещения одной накопительной дисконтной карты другой.
Процедура замещения накопительной дисконтной карты позволяет учитывать предыдущую активность покупателя в случае выдачи ему новой дисконтной карты взамен утерянной или испорченной.
Процедура «Заместить дисконтные карты» вызывается кнопкой «Обработать», относящейся к списку дисконтных карт накопительного типа. Процедура позволяет заместить одну или более выбранных карт другой дисконтной картой. При замещении тех дисконтных карт, которые сами замещают какие-либо дисконтные карты, ссылка замещения для ранее замещенных карт меняется на новую карту.
Замещенная дисконтная карта блокируется, и ее разблокирование не разрешается.
Замещать дисконтную карту нужно только дисконтной картой того же типа.
Процедура замещения позволяет указать процедуре расчета накопительной скидки на то, что при расчете суммарной активности покупателя необходимо учитывать не только активность по данной дисконтной карте, но и активность по всем тем дисконтным картам, которые были замещены данной картой. Сами замещенные карты в расчете новых значений скидок не участвуют.
В процедуру ввода штрихового кода при регистрации нового штрихового кода для артикула введена дополнительная проверка контрольной суммы. Проверка предназначена для предупреждения возможных ошибок оператора при ручном вводе штриховых кодов. Контрольная сумма проверяется по алгоритмам для кодов типов EAN и UPC. Проверка предупреждает оператора о несоответствии введенной последовательности цифр стандартам EAN и UPC, но не запрещает ввести новое значение.
Если штриховой код относится к иному типу, чем EAN или UPC, то проверка будет срабатывать избыточно. Однако иные типы штриховых кодов для идентификации товаров используются редко, например, это могут быть короткие коды для товаров, на которые нельзя нанести код или этикетку, соответственно, считается, что избыточное предупреждение не должно затруднять работу оператора.
В структуру заголовка почтового пакета внесено изменение для передачи вместе с пакетом информации о версии почтового объекта. Изменение коснулось только пакетов в формате sm2000. Файлы формата XML информацию о версии почтового объекта не содержат.
Под версией почтового объекта понимается дата и время его последнего обновления в локальной базе данных, либо версия последнего приема, в зависимости оттого, что имеет большее значение и имеется ли информация о последнем изменении объекта в торговой системе. Дата и время изменения, которые принимаются в качестве версии почтового объекта, преобразовываются в систему абсолютного времени по Гринвичу.
При приеме почтового пакета для каждого объекта, поступившего в составе пакета, может быть осуществлена проверка старшинства версий почтового объекта и его локальной копии. Функция проверки версии почтового объекта включается в административном модуле в разделе «База данных» на странице «Конфигурация» в новой папке «Почта». По умолчанию функция отключена.
Для правильной работы функции контроля необходимо, чтобы опция «Контроль версий почтовых объектов» была включена и в отсылающей и в принимающей базе данных. В отсылающей базе данных опция включает механизм определения и записи номера версии в заголовок почтового объекта. В принимающей базе данных включает функцию сличения версии локальной копии объекта и версии почтового объекта.
На той же странице настраивается смещение локального времени относительно абсолютного времени по Гринвичу – общее смещение и дополнительное смещение за счет летнего времени. Для часового пояса Москвы смещение составляет +3 часа. Летнее время добавляет еще 1 час. При настройке смещения необходимо учитывать, что несинхронная настройка смещения в разных базах данных приведет к неверному определению старшинства версий.
Если функция контроля версии почтового объекта включена, то при приеме почтового объекта определяется версия его локальной копии и если локальная копия имеет более позднюю версию, чем у почтового объекта, почтовый объект в базу данных не принимается. Под версией локальной копии объекта понимается либо дата время его последнего изменения, либо последняя версия ранее принятого почтового объекта. Версия локального объекта определяется в системе абсолютного времени по Гринвичу.
Если для локального объекта нет информации о дате времени его последнего изменения и такой объект никогда не принимался по почте, то считается, что локальный объект имеет заведомо более раннюю версию, чем объект, принимаемый по почте.
При приеме почтовых объектов, версия которых в пакете не указана, например, при приеме пакетов в формате XML, считается, что принимаемый объект имеет заведомо более позднюю версию.
При отсылке почтовых объектов, имеющих историю изменений, например, документов, дата время отсылки объекта не считается временем его последнего изменения. При приеме почтовых объектов дата время изменения объекта по факту предыдущего приема по почте, то есть изменения почтовым модулем, не учитывается при определении его версии. Для определения версии локальной копии учитывается версия ранее принятого объекта и изменения, совершенные в локальной базе данных. Версия ранее принятых объектов сохраняется в отдельной таблице, интерфейс к которой отсутствует.
Для объектов, не имеющих историю, например, для справочников, версия при отсылке считается неопределенной.
Механизм контроля версии обеспечивает корректный прием почтовых отправлений при однонаправленной пересылке объектов, например справочников из старшей базы данных в младшие, а также при обмене документами, которые изменяются только в одной базе данной.
При использовании механизма контроля версии почтовых объектов необходимо учитывать, что данный механизм не решает проблемы одновременного редактирования одного и того же объекта в разных базах данных с выяснением, какое из изменений является правильным. В текущем алгоритме последней версией будет признана версия экземпляра объекта, который был изменен последним по времени, если речь идет об объекте с ведением истории или объект, который был послан позднее.
Описанный выше механизм контроля версии принимаемого почтового объекта не решает задачи контроля последовательности исполнения актов переоценки, то есть проблемы, которая возникает при нарушении во времени порядка исполнения актов переоценки.
В случае нарушения порядка передачи из одной базы данных в другую двух актов переоценки для одного и того же артикула, механизм контроля версии почтовых объектов позволит принять и исполнить оба акта переоценки, поскольку это разные почтовые объекты.
Для защиты от неверной последовательности исполнения актов переоценки разработан механизм контроля последовательности исполнения актов переоценки. Этот механизм позволяет проверить для каждого артикула из исполняемого акта переоценки наличие ранее исполненного акта переоценки, который в действительности должен был быть исполнен после исполнения текущего акта.
Порядок исполнения актов переоценки определяется только для актов с условием исполнения «немедленно при оприходовании». Считается, что исполнение всех актов переоценки с условием исполнения – «по наступлению указанной даты» или «при оприходовании документа-основания» должно происходить именно в тот момент времени, когда это реально произошло.
Для актов переоценки с условием исполнения «немедленно при оприходовании» введен атрибут – предполагаемая дата и время исполнения, который заполняется текущим временем в момент принятия акта к исполнению. В дальнейшем, если возникает временной разрыв между принятием акта к исполнению и исполнением акта, то осуществляется проверка наличия ранее исполненного акта переоценки с датой-временем предполагаемого исполнения большим, чем дата-время предполагаемого исполнения текущего акта. Для актов с иными причинами исполнения предполагаемое время исполнения считается равным фактическому времени исполнению.
Сравнение даты и времени предполагаемого исполнения производится в системе абсолютного времени по Гринвичу. Для правильной работы процедуры в каждой базе данных необходимо задать смещение времени относительно времени по Гринвичу и указание на наличие зимнего времени. Установка этих величин производится в административном модуле в разделе «База данных» на странице «Конфигурация» в группе данных «Почта».
В процессе контроля исполнения акта переоценки все артикулы, для которых цена не может быть установлена по причине того, что текущий акт для них является слишком старым, переносятся из текущего акта переоценки в новый документ, который в свою очередь переводится в статус «Заблокирован». Если все цены акта переоценки являются слишком старыми, то новый документ не создается, а исходный документ переводится в статус «Заблокирован». Если новый документ создается, то него в качестве основания прописывается исходный акт переоценки и в оба документа добавляется пометка в поле комментарий.
Описанный механизм контроля будет работать только при установленной опции административного модуля «Контроль порядка исполнения цен» в разделе «База данных» на странице «Конфигурация» в группе данных «Ценообразование».
В предыдущих версиях системы, при печати этикеток с ценой из накладной на перемещение цена в этикетку проставлялась из таблицы текущих цен для места хранения «В» накладной по виду цены для кассы этого места хранения.
В текущей версии введен следующий алгоритм поиска цены для печати в этикетке:
Цена берется из акта переоценки, который создан на основании накладной на перемещение и имеет следующие атрибуты: вид цены акта совпадает с видом цены для кассы места хранения «В», место хранения акта равно месту хранения «В» накладной на перемещение, статус акта - «принят к исполнению» или «исполнен».
Если артикул из накладной в таком акте отсутствует или отсутствует сам акт, то цена берется из таблицы текущих цен. Вид цены берется как вид цены для кассы места хранения «В». Место хранение цены определяется следующим образом: это либо место хранения «Из» накладной на перемещение, если это место хранения является локальным для базы данных, иначе это место хранения «В» накладной на перемещение, если оно является локальным для базы данных, иначе цена считается неопределенной.
Новый алгоритм поиска цены позволяет печатать этикетки с ценой, как при формировании поставки перемещаемого товара, так и при его приеме с учетом того, что базы данных, в которых будет происходить регистрация движения товара, будут разными. При этом цена на этикетке будет такая, которая либо должна быть установлена на перемещаемый товар в момент его приема в месте приема, либо соответствует его текущей цене в месте приема, если новую цену устанавливать не предполагается. Данный алгоритм рассчитан только на создание этикеток для нового товара, то есть не предполагается, что он будет использоваться для обработки возвращаемого товара.
В предыдущих версиях торговой системы интерфейс для управления работой почтового модуля располагался в панели управления компьютера в папке «Службы и приложения» вместе с интерфейсами управления кассовым модулем, сервером Супермага и модулем контроля цен Супермага.
В текущей версии интерфейс управления почтовым модулем вынесен из панели управления компьютером в отдельное приложение «Администратор почтового модуля».
Сам почтовый модуль, который реализован как служба операционной системы «Почтовый модуль Супермага», остался прежним, и его функциональность не изменилась. Как и прежде, одну базу данных должна обслуживать единственная служба почтового модуля. Для большинства случаев достаточно функционирования единственной службы почтового модуля на одном компьютере сети.
Администратор почтового модуля может быть установлен как на том же компьютере, где установлена и эксплуатируется служба, так и на любых других компьютерах сети. Администратор почтового модуля может эксплуатироваться несколькими пользователями одновременно на разных компьютерах и управлять, при этом, одной службой почтового модуля.
Для управления взаимодействием администратора почтового модуля и службы почтового модуля при работе на разных компьютерах в состав почтового модуля включена служба – «Удаленное управление почтовым сервером Супермага». Служба всегда устанавливается вместе со службой «Почтовый модуль Супермага».
Для раздельной установки служб почтового модуля и администратора почтового модуля внесены изменения в программу установки торговой системы. На странице «Выбор компонентов» в состав компонента «Почтовый модуль» включены две части: «Администратор почтового модуля» и «Служба почтового модуля». При установке метки на компоненте «Почтовый модуль», по умолчанию отмечаются обе части.
При установке администратора почтового модуля в среде операционной системы Windows XP при первом запуске программы будет получено сообщение от брандмауэра о необходимости блокировки или разблокировки доступа к программе по сети. Необходимо разблокировать доступ к программе по сети или поместить программу SM.Post.Admin.exe в список исключений центра обеспечения безопасности Windows до ее первого использования.
Интерфейс администратора почтового модуля состоит из трех разделов – страницы выбора компьютера службы почтового модуля, страницы управления службой почтового модуля и страницы управления почтовым обменом.
При старте администратора почтового модуля необходимо в первую очередь указать компьютер, на котором функционирует служба почтового модуля для установления связи с ним. Это может быть локальный компьютер, и тогда его имя указывать необязательно, или удаленный компьютер. В этом случае на странице выбора службы почтового модуля необходимо указать доменное имя компьютера, на котором размещена служба. В случае успешного соединения это имя запоминается и используется при последующих запусках администратора. Настройки для старта администратора запоминаются на локальном компьютере для каждого пользователя ОС раздельно.
Страница управления службами почтового модуля состоит из двух частей – части для управления функционированием служб и части для управления взаимодействия с базами данных.
Элементы управления службами позволяют остановить или запустить службу и настроить свойства службы – тип запуска и пользователя, от имени которого стартует служба, и права которого она наследует. При указании пользователя, от имени которого стартует служба, необходимо учитывать, что почтовый модуль может работать с сетевыми каталогами и в этом случае прав пользователя по умолчанию «Local system» может оказаться недостаточно. Для получения достаточных прав как для работы с ресурсами локального компьютера, так и для работы с сетевыми ресурсами, необходимо для старта службы указывать пользователя с правами администратора домена.
Полное управление обоими службами средствами администратора почтового модуля доступно только при старте администратора на локальном компьютере, то есть на том же компьютере, на котором функционируют службы и только пользователю с правами администратора. При работе с удаленного компьютера управление службой «Удаленное управление почтовым сервером Супермага» не допускается. Управление службой «Почтовый модуль Супермага» разрешено только пользователям, перечисленным в списке администраторов почтового модуля.
Перечень пользователей, которым будет разрешено управлять службой почтового модуля с удаленных компьютеров, задается для службы удаленного управления. При задании имени необходимо указывать полное имя пользователя, включая имя домена. Администратор почтового модуля, указанный в перечне, не обязан обладать правами администратора домена для дальнейшего управления службой почтового модуля с удаленного компьютера.
Список администраторов почтового модуля и настройки служб хранятся на том же компьютере, на котором функционируют службы, и при переносе службы на иной компьютер требует повторного ввода. Вся информация сохраняется в зашифрованном виде.
Управление службами, а именно, старт, останов и настройка их свойств, может также осуществляться средствами операционной системы через консоль управления компьютером, однако в этом случае пользователь при работе с удаленного компьютера должен обладать правами администратора домена.
Необходимым условием старта администратора почтового модуля с удаленного компьютера является функционирование службы удаленного управления на компьютере, к которому осуществляется подключение. В связи с этим необходимо следить за тем, чтобы эта служба всегда запускалась автоматически при старте компьютера-сервера и не была остановлена.
Если служба удаленного управления не запущена, то при попытке администратора почтового модуля установить соединение со службами почтового модуля на другом компьютере, будет получено сообщение об ошибке.
Если пользователь, стартующий администратор почтового модуля с удаленного компьютера, не зарегистрирован как администратор почтового модуля, то ему разрешается работа с функциями почтового модуля в рамках его прав на функции модуля «Почтовый модуль», но не разрешаются действия, связанные с управлением службами и регистрацией баз данных.
В большинстве случае одна служба почтового модуля обслуживает одну базу данных, то есть обеспечивает прием данных в одну базу данных и отсылку данных из нее. Тем не менее, служба может обслуживать несколько баз данных, работая с каждой из них независимо.
Для работы почтового модуля, прежде всего, необходимо указать перечень обслуживаемых баз данных, их атрибуты, и пароль для соединения от имени пользователя supermag. Эти данные будут использоваться службой почтового модуля для соединения с базой данных после того, как им будет получена команда активизации процесса отсылки или приема почтовых отправлений.
Создание нового описания базы данных, его изменение или удаление описания осуществляется в группе элементов «Регистрация базы данных».
Параметры соединения, указанные при регистрации базы данных, не используются для работы с базой данных администратором почтового модуля. Для задания настроек почтового обмена или получения информации о состоянии почтового обмена из таблиц базы данных, пользователь должен указать свое имя и пароль.
Диалог для ввода имени и пароля выдается всякий раз при первом обращении к информации или функциям базы данных. Последнее введенное имя запоминается и подставляется в диалог при следующем старте администратора почтового модуля и новом обращении к базе данных. В пределах текущей сессии работы администратора также запоминается пароль, но при следующем старте он не восстанавливается.
Базы данных, с которыми установлено соединение в рамках текущей сессии работы администратора почтового модуля, помечаются синей галочкой. Это не означает, что с этой базой работает или не работает служба почтового модуля. Это означает то, что администратор почтового модуля может обратиться к базе данных без дополнительного ввода имени и пароля. Активность службы почтового модуля при работе с базой данных обозначается зелеными стрелками на пиктограмме базы данных. Стрелка влево – прием, вправо – отсылка. При завершении работы администратора все его соединения автоматически закрываются.
Права пользователя при работе с администратором почтового модуля по отношению к функциям управления почтового обмена определяется правами должности в административном модуле.
Для детального управления правами пользователей в модульную роль «Почтовый модуль» добавлены функциональные роли: «Конфигурация и настройка» и «Управление». Право «Конфигурация и настройка» позволяет редактировать параметры обмена и правила рассылки, право «Управление» позволяет управлять очередями приема и отсылки пакетов и объектов.
Настройка параметров рассылки включает описание перечня абонентов - удаленных баз данных, форматов обмена, способа доставки - транспортов и периодичности работы, а также правил автоматической рассылки.
Определение параметров функционирования почтового модуля при работе с базой данных возможно только при остановленном почтовом обмене. При следующем старте процессов почтового обмена будут использованы новые значения настроек.
Настройка параметров обмена почтового модуля.
Общие параметры функционирования почтового модуля, которые не связаны с тем или иным абонентом (удаленной базой данных) задаются на странице «Параметры обмена».
В группе «Запуск» устанавливаются флаги автоматического старта процессов приема и отсылки почтовых отправлений при старте службы почтового модуля. Если условие автостарта не задано, служба почтового модуля после старта не обращается к базе данных до получения явной команды из администратора почтового модуля.
В группе «Ведение журналов» устанавливаются флаги для журнализации событий по отправке и приему почтовых пакетов и объектов. Настройка автоматического удаления старых записей позволяет избежать неконтролируемого роста объема журналов.
В группе «Пакеты» задаются общие правила поведения службы почтового модуля. При установке параметра «Число потоков для приема входящих пакетов» следует иметь в виду, что реальное число потоков будет не больше, чем число абонентов, от которых принимаются пакеты. Если заданное число потоков меньше количества абонентов, то организуется очередь потоков, и пакеты от следующего абонента принимаются после завершения работы одного из ранее занятых потоков. Также следует иметь в виду, что использование большого числа потоков может приводить не к росту, а к замедлению скорости работы почтового модуля из-за особенностей поведения операционной системы.
Описание перечня абонентов – удаленных баз данных осуществляется на странице «Удаленные базы данных». Здесь же для каждой удаленной базы описывается формат обмена и вид транспорта.
Интервал времени между очередными попытками работы транспорта (частота опроса) теперь задается в окне параметров транспорта и может быть задано раздельно для транспорта каждого абонента.
Настройка правил автоматической рассылки.
Автоматическая рассылка объектов зависит от правил постановки объектов в очередь на рассылку и от перечня мест хранения, обслуживаемых удаленной базой данных.
В правилах отсылки описание располагается на двух страницах – «Правила рассылки» и «Места хранения».
Правила отсылки описывают события, при которых тот или иной тип объекта должен быть поставлен в очередь на отсылку, и категорию базы данных – старшая и/или подчиненная. Автоматическая рассылка в равноправные базы не поддерживается. В случае рассылки в подчиненные базы данных правила рассылки подразумевают, что объект будет отослан в подходящие базы данных. Под подходящими базами подразумеваются либо все подчиненные базы данных (для тех объектов, которые логически не связаны с понятием места хранения) либо только те подчиненные базы данных, которые обслуживают места хранения, логически связанные с объектом.
Необходимо учитывать, что при автоматической рассылке объектов, содержащих место хранения, например, документов, объект действительно будет поставлен в очередь на отсылку только в ту подчиненную базу данных назначения, для которой указано место хранение такое же, как и в объекте.
Одно и то же место хранения нельзя приписывать к нескольким удаленным базам данных. Также необходимо следить за тем, чтобы одно и то же место хранения не было описано как локальное, то есть обслуживаемое в текущей базе данных и как обслуживаемое одной из удаленных баз данных.
Правила рассылки также позволяют описать правила пересылки объекта для тех случаев, когда топология баз данных подразумевает прохождение объекта от одной базы данных к другой через одну или несколько промежуточных баз данных. Правила сквозной рассылки описываются по отношению к текущей базе данных, учитывая ее положение в топологии баз данных. При сквозной пересылке объектов, логически связанных с местом хранения, пересылка в подчиненные базы данных происходит по тому же принципу, что и при отсылке, то есть объект пересылается только в подходящие базы данных. Соответственно, при описании мест хранения удаленных баз данных, для каждой удаленной базы данных необходимо описывать не только те места хранения, которые обслуживает эта база данных, но и те мест хранения, которые обслуживаются всеми подчиненными ей базами данных, то есть всеми базами данных, стоящими за ней в цепочке баз данных.
Необходимо учитывать, что не все типы объектов могут рассылаться автоматически. Для таких объектов разрешается задавать правила сквозной пересылки, но не позволяется задавать правила автоматической постановки в очередь на отсылку.
Страница управления почтовым обменом позволяет осуществлять старт и остановку процессов отсылки и приема пакетов и контролировать ход почтового обмена.
Команды управления почтовым обменом.
Команды управления процессом отсылки и приема продублированы опциональными командами посылки и приема пакетов подтверждения. По умолчанию, при старте процесса отправки пакетов с информацией автоматически включается процесс приема пакетов подтверждения с информацией о прохождении отосланных объектов. При старте процесса приема пакетов с данными по умолчанию включается процесс отсылки пакетов подтверждения об успешности приема. При отключении процессов связанные с ними процессы обработки пакетов подтверждения также останавливаются. Тем не менее, остается возможность ручного раздельного управления процессами отсылки и приема пакетов подтверждения.
Очередь отсылки.
Страница «Очередь отсылки» предназначена для просмотра состояния процесса пересылки объектов, поставленных в очередь на отсылку, и управления очередью отсылки объектов. Эта возможность в предыдущих версиях интерфейса почтового модуля не предоставлялась.
Информация об объекте отображается на странице, начиная с момента постановки его в очередь на отсылку и до момента получения подтверждения об успешном приеме объекта ото всех получателей, либо до момента удаления объекта из очереди.
В колонке «Статус» показывается состояние пересылаемого объекта:
«в очереди» - идентификатор объекта помещен в очередь на отправку (информация о необходмости отослать объект),
«формируется» - объект находится в процессе размещения в виртуальном пакете,
«в пакете» - объект размещен в физическом пакете, пакет создан и помещен в каталог отсылки,
«отослан» - файл физического пакета отослан транспортом.
В колонке «ошибки» отображается факт наличия или отсутствия ошибок при пересылке объекта. Для просмотра подробного сообщения об ошибках надо два раза нажать левой клавишей мыши на изображении пиктограммы ошибки.
Для ограничения списка просматриваемых объектов в очереди можно задать фильтр очереди отсылки. Фильтр может быть установлен по типам объектов, базам данных назначения, коду объекта, статусу продвижения объектов, номеру виртуального почтового пакета, диапазону времени создания пакетов и факту наличия или отсутствия ошибок при пересылке объекта.
Для управления очередью имеется возможность удаления объекта из очереди. Из очереди можно удалять только те объекты, которые еще не начали движение.
Имеется возможность внеочередной отсылки объекта. То есть инициации немедленной отсылки объекта без контроля его места в последовательности отсылаемых объектов. Немедленная отсылка может осуществляться только квалифицированными пользователями и только в черезвычайных ситуациях, например, при необходимости срочной отправки объекта в условиях большого трафика и низкой пропускной способности сети.
Очередь отсылки пакетов.
Страница по содержанию аналогична такому же интерфейсу предыдущей версии. В таблице виртуальных пакетов отображается состояние обработки виртуальных пакетов: «В очереди» и «Создан». В таблице физических пакетов состояние обработки физического пакета: «В очереди», «Создан» и «Принят».
Состояние «В очереди» по отношению к пакету означает, что пакет находится в процессе формирования.
В обоих таблицах продублированы отметки о наличии ошибок почтового обмена. В таблице виртуальных пакетов отметка об ошибке появляется при наличии хотя бы одной ошибки при обработки как виртуального, так и физических пакетов, созданных на основании виртуального.
В таблице физических пакетов отметка об ошибке показывается только для тех пакетов, при обработке которых возникла ошибка.
Очередь принимаемых пакетов.
Страница «Прием пакетов» предназначена для просмотра состояния процесса приема физических пакетов, пришедших из удаленных баз данных. Эта возможность в предыдущих версиях интерфейса почтового модуля не предоставлялась.
Функции управления очередью позволяют принять пакет вне очереди, то есть имеется возможность немедленной инициации процесса приема независимо от периода времени обработки пакетов и очередности полученных пакетов.
Журналы.
На страницах «Журнал отсылки» и «Журнал приема» отображается информация из соответствующих журналов. Журнализация процессов отсылки и приема ведется только в том случае, когда журналы включены. В те моменты, когда журналы отключены, информация о прохождении процессов в них не попадает и после последующего включения журналов не восстаналивается.
Внесено изменение в алгоритм работы полной принудительной загрузки касс по расписанию.
В предыдущих версиях алгоритм принудительной полной выгрузки с условием «Один раз в указанное количество дней … В указанное время …» выполнялся следующим образом: в ходе выполнения расписания загрузок касс очередная загрузка принудительно заменялась на полную, если текущее время превысило время, указанное в настройке, и интервал времени после предыдущей принудительной полной выгрузки составил не менее 24 часа * количество дней.
В текущей версии условие наступления полной принудительной выгрузки изменено. В ходе выполнения расписания загрузок касс очередная загрузка принудительно заменяется полной загрузкой, если текущее время превысило время, указанное в настройке, и разница в днях между текущей датой и датой полной предыдущей загрузки касс больше или равно заданному количеству дней.
Изменение алгоритма обеспечивает условие старта полной принудительной загрузки в ближайшую загрузку по расписанию после указанного времени, если в течение текущих календарных суток еще не производилось полной принудительной загрузки. В предыдущих версиях наблюдалось смещение времени полной принудительной загрузки в более позднюю сторону, если первый старт полной принудительной загрузки происходил позднее заданного времени, например, при первом старте после настройки расписания.
При выгрузке информации в кассы УКМ2 производится приведение данных торговой системы к формату УКМ2. В частности, УКМ2 не допускает наличие в дереве классификаторов групп 6-го и более уровней. В процессе загрузки касс классификатор приводится к формату УКМ2 за счет удаления из него групп шестой и более уровня вложенности и осуществляется перенос артикулов в родительские группы 5-го уровня. В предыдущих версиях драйвер кассы при выгрузке классификатора заносил сообщение об ошибке столько раз, сколько групп классификатора 6-го или более уровней встречалось в исходном классификаторе, и при выгрузке артикулов заносил сообщение об ошибке всякий раз при переносе артикула в родительскую группу.
В текущей версии сообщение об ошибке выдается один раз для классификатора с перечислением первых пяти отсеченных групп и один раз для артикулов с общим предупреждением о возможной потере информации о скидках и других атрибутах, назначенных артикулу через усеченные группы классификатора.
Разработан драйвер касс для работы с кассовым сервером УКМ4. Драйвер использует в качестве среды обмена базу данных MYSQL. Перед началом использования драйвера внимательно до конца прочтите данный раздел.
Для работы драйвера необходимо предварительно обеспечить следующие условия:
Java Server может быть установлен в процессе создания экземпляра базы или установлен позднее. Если экземпляр базы данных создается с помощью программы Oracle Database Configuration Assistant, то для установки Java Server необходимо выбрать флажок Oracle JServer на странице выбора опций для конфигурирования базы данных. Если экземпляр базы данных уже создан, то для установки Java Server необходимо в той же программе Oracle Database Configuration Assistant выбрать режим Change database configuration и на странице выбора опций для конфигурирования базы данных установить флаг Oracle Jserver. Если Java Server был ранее установлен, то флаг Oracle Jserver будет отмечен и недоступен для редактирования.
Установить Oracle Jserver можно также выполнив скрипт:
%ORACLE_HOME%\javavm\install\ initjvm.sql
где %ORACLE_HOME% - путь к каталогу, в котором размешаются фалы Oracle, например, с:\Ora81. Не следует использовать путь Oracle home для Oracle 8.0
При установке Jserver на уже существующий экземпляр базы данных обязательно необходимо предварительно проверить следующие параметры базы данных
1. SHARED_POOL_SIZE >= 65 MB
JAVA_POOL_SIZE >= 50 MB
50 MB свободного пространства в табличном пространстве SYSTEM
250 MB свободного пространства в табличном пространстве сегмента отката
2. Переменная NLS_LANG должна быть задана корректно: AMERICAN_AMERICA.CL8MSWIN1251, RUSSIAN_CIS.CL8MSWIN1251
В случае неудачной установки, например из-за несоблюдения вышеперечисленных требований к экземпляру базы данных, необходимо перед повторной попыткой удалить объекты, оставшиеся от предыдущей попытки. Сделать это можно, выполнив скрипт:
%ORACLE_HOME%\javavm\install\ jvmrm.sql
Для установки драйвера JDBS mySql необходимо скопировать на компьютер каталог mysql-connector-java-2.0.14, затем запустить интерфейс командной строки, в интерфейсе командной строки перейти в каталог mysql-connector-java-2.0.14 и в нем выполнить файл:
%ORACLE_HOME%\bin\loadjava.bat -user <имя пользователя>/<пароль>@<имя БД> -o -r -g public -s mysql-connector-java-2.0.14-bin.jar
где %ORACLE_HOME% - путь к каталогу, в котором размешаются фалы Oracle, например, с:\Ora81.
Имя пользователя должно быть SYS. Для баз данных Oracle с версией до 9.2.0.3 необходимо гарантировать, что пользователю SYS назначено строго меньше 148 ролей. Если ролей 148 или больше, то процедура пройдет с ошибкой. Если выяснилось, что ролей больше, чем это допускается, необходимо отозвать часть ролей и повторить попытку.
Если, перечисленные выше компоненты базы данных Oracle не установлены, то часть компонентов схемы Supermag установлена не будет. Это означает, что если необходимость использования драйвера кассы УКМ4 возникла уже после установки текущей версии торговой системы, то необходимо не только установить вышеперечисленные системные компоненты, но и повторно загрузить пакеты схемы Supermag с помощью программы «Генератор базы данных».
Настройка драйвера УКМ4 проводится в разделе «Структура магазина/склада» для группы отделов. Для драйвера УКМ4 необходимо указать параметры двух баз данных mySQL, для загрузки данных в сервер УКМ4, и для получения данных о кассовых продажах. При задании параметров баз данных номер порта можно не задавать, если он соответствует значению по умолчанию 3306.
При настройке драйвера УКМ4 необходимо учитывать, что касса УКМ4 в соответствует не одной кассе, а кассовой линейке, которая в торговой системе соответствует понятию группы отделов. Соответственно, для одной группы отделов необходимо задавать не более одной кассы УКМ4. В остальном принцип функционирования драйвера УКМ4 не отличается от функционирования других драйверов касс. Драйвер УКМ4 может применяться совместно с любыми другими драйверами касс, включая драйверы УКМ2.
В процедуру расчета товародвижения добавлена возможность вывода в файл информации о ходе процесса расчета.
Вывод информации осуществляется, если в диалоге старта расчета указано включить трассировку для одного выбранного артикула.
Опция включения трассировки, элементы диалога для задания артикула и файла для вывода информации размещены в административном модуле в диалоге старта процедуры расчета товародвижения. При каждом новом открытии окна диалога старта расчета флаг трассировки устанавливается в выключенное положение для того, чтобы избежать случайного замедления процесса расчета.
Пример строки трассировки:
MapOutIn :
приход: WI 1МБ7407/1, оп.:0, MX:->3, кол.18(18)
расход: IW НпЗ3253/1, оп.:4, MX:3->1647, кол.6(6) / объем движения: 6
MapOutIn : - название шага расчета. Далее идет пара связанных документов
WI 1МБ7407 – тип и номер документа.
/1 – номер строки спецификации.
оп.:0 – код операции.
MX:->3 – код места хранения и направление движения товара.
кол.18(18) – количество в документе и количество доступное для распределения.
кол.6(6) / объем движения: 6 – количество в документе (доступное к распределению)/распределенное.
В стандартный диалог для старта пользовательских отчетов добавлены следующие элементы диалога для управления параметрами старта отчета:
Использование флажков может быть любым в зависимости от назначения отчета. Выбор контрагента может осуществляться среди поставщиков или клиентов.
При настройке пользовательского отчета можно указать, какие из элементов диалога будут использоваться и показываться на экране. Для элементов «Флажок 1» … «Флажок 5» помимо этого можно указать название, которое будет показываться на экране вместо слов «Флажок 1» и т.д. Для элемента выбора контрагента можно задать вариант использования – поставщик или клиент.
Описание элементов диалога задается в разделе «Настройка отчетов» в диалоге «Параметры отчета» текстовой строкой с условным описанием полей. По умолчанию, если строка не задана, показываются все элементы диалога.
Например, следующая строка позволит в диалоге показать один флаг с названием «только итоги» и элемент диалога для выбора поставщика:
SUPP;1;2|FLAG1;1;только итоги|FLAG2;0|FLAG3;0|FLAG4;0|FLAG5;0
Подробное описание способа управления элементами стандартного диалога старта отчета имеется в файле RepExample_ReadMe.doc, который устанавливается на компьютер программой установки торговой системы при выборе опции «Примеры пользовательских отчетов».
В торговой системе существует функция автоматического старта программы установки клиентской части программы, если при попытке запуска программы обнаруживается расхождение между версией базы данных и версией или сервис паком клиентской части.
В предыдущих версиях запуск программы установки всегда происходил от имени текущего пользователя и с его правами доступа к ресурсам компьютера.
В тех случаях, когда установка торговой системы требовала внесения изменений в реестр локального компьютера, и текущий пользователь не обладал правами на его изменение, такая установка не заканчивалась успешно.
В текущей версии можно указать пользователя с достаточными правами, например администратора сети, от имени которого будет производиться автоматический запуск программы установки.
Регистрация пользователя, от имени которого будет запускаться программа установки Супермага при автоматическом обновлении версии клиентской части, производится в административном модуле в разделе «База данных» в группе данных «Инсталляция».
Для описания пользователя необходимо задать имя пользователя, домен пользователя и его пароль. Пароль сохраняется в зашифрованном виде. Все данные о пользователе для программы установки сохраняются в базе данных и используются всеми компьютерами сети при автоматическом обновлении версии. При определении такого пользователя необходимо, чтобы он обладал достаточными правами на всех компьютерах сети.
Если имя пользователя не указано, то запуск инсталлятора будет осуществляться по прежнему алгоритму, то есть от имени текущего пользователя.
Имя и права привилегированного пользователя используются только при автоматическом запуске программы установки. При ручном старте программы установки эти данные не используются.
Новые возможности по автоматической установке клиентской части с правами администратора будут доступны только при модернизации версии 1.025 или старше на еще более старшие версии или сервис паки.
Внесены изменения в систему лицензионной защиты. Изменения касаются формата лицензионной записи и не сказываются на общем функционировании системы.
Изменения функционала в версии 1.025.1
Маркетинговая акция.
Дата и время исполнения маркетинговых акций.
Описание мест хранения и видов цен в маркетинговой акции.
Исполнение маркетинговых акций.
Контроль полноты исполнения маркетинговой акции.
Почтовая рассылка и почтовый прием маркетинговых акций.
Акты переоценки. Информационные поля для контроля переоценки.
Складские требования. Контроль количества.
Генерация заказов по контрактам с выбором мест хранения.
Подбор оснований в порядке поставок.
Функция проверки «Дата документа больше текущей даты».
Функция проверки «Запрет принятия в ценах сличительной ведомости с нулевыми суммами»
Групповое изменение уровней складских запасов для списка мест хранений.
Полный перерасчет остатков.
Расчет себестоимости движения до первого прихода.
Фильтр загрузки товаров на весы.
Почтовый модуль.
Доверительная база данных.
Синхронизация объектов в базах данных.
Пересылка документов с собственными контрагентами.
Пересылка актов потерь в старшую базу данных.
Рассылка пользовательских операций.
Модуль контроля цен.
Внутренняя база данных.
Администрирование модуля контроля цен.
Удаленное администрирование.
Протокол обмена с торговой системой.
Сводный товарный отчет.
Товарный отчет по форме ТОРГ-29.
Форма печати ТОРГ-12.
В содержание и поведение документа «Маркетинговая акция» внесены изменения для упрощения контроля процесса проведения маркетинговой акции. Смысл и технология процесса остались прежними. В связи с изменением структуры документа перед установкой версии необходимо завершить все действующие маркетинговые акции.
Дата начала и завершения маркетинговой акции дополнены временем начала и завершения маркетинговой акции. По умолчанию, при создании маркетинговой акции, теперь будет предлагаться акция для следующего дня с 00:00 по 23:59.
Использование времени в сроке старта и завершения акции требует, чтобы расписание периодической процедуры исполнения маркетинговой акции было настроено с таким интервалом активности, при котором задержка между заданным временем исполнения акции и реальным временем исполнения была бы в допустимых пределах. Например, планируя акцию с точностью до часа, не следует задавать расписание работы процедуры один раз в день. Расписание следует задавать с интервалом как минимум в 10 минут.
Периодическая процедура исполнения маркетинговых акций выделена из периодической процедуры «Регистрация актов переоценки», которая теперь осуществляет только исполнение актов переоценки с заданной датой / временем исполнения. Процедура для маркетинговых акций получила название «Исполнение / завершение маркетинговых акций» и помещена в группу системных заданий.
После установки текущей версии строго необходимо провести настройку нового задания, если до этого задание «Регистрация актов переоценки» использовалось, в том числе, для исполнения маркетинговых акций.
Изменен способ ввода в документ перечня мест хранений и видов цен, по которым будет проводиться маркетинговая акция. В предыдущих версиях вначале надо было указать вид цены, а затем место хранения из перечня мест хранений, в которых данный вид цены разрешен к использованию.
В текущей версии вначале необходимо добавить место хранение или список мест хранений, а виды цен подставляются по умолчанию, как виды цен для кассы выбранных мест хранений. Вся информация помещается в одну таблицу. Ввод перечня мест хранения осуществляется в диалоге выбора мест хранений, который вызывается по кнопке «добавить». Если надо удалить места хранения из таблицы, необходимо выделить необходимые строки и нажать кнопку «удалить».
При необходимости изменить или расширить перечень видов цен, по которым будет проводиться маркетинговая акция для данного места хранения, надо нажать кнопку в ячейке вида цены. Если видов цены для места хранения выбрано несколько, они будут показываться в ячейке видов цен через запятую.
Для однозначного планирования и контроля процесса исполнения маркетинговых акций в сети распределенных баз данных введено понятие локального и центрального исполнения маркетинговой акции для места хранения.
Локальное исполнение подразумевает, что акты переоценки начала и завершения маркетинговой акции для указанного места хранения будут создаваться только в той базе данных, которая обслуживает данное место хранения как локальное. Центральное исполнение маркетинговой акции для места хранения подразумевает, что акты переоценки для этого места хранения будут создаваться только в той базе данных, которая обслуживает место хранения - источник акции.
Для управления режимом исполнения маркетинговой акции в таблицу мест хранения акций добавлена колонка «Локальное исполнение». По умолчанию для всех выбранных мест хранений проставляется значение «Да».
Выбор режима проведения акции – локальное или центральное, зависит от принятой в торговой организации технологии управления магазинами и оперативностью обмена информацией с базами данных магазинов. Например, при локальном исполнении необходимо включать периодическую процедуру исполнения маркетинговых акций на серверах подчиненных баз данных, что несколько увеличивает степень сложности администрирования сети баз данных, но при этом снижается зависимость процесса от периодичности и устойчивости средств связи почтового обмена. Для точного исполнения акции достаточно заранее передать документ в магазин и в нужное время процесс выполнится автоматически. При центральном исполнении процесс полностью проводится в центре, а в подчиненные базы данных только отправляются акты переоценки. В этом случае управление процессом становится проще, но возникает вероятность задержек конечного исполнения актов переоценок из-за потерь времени при транспортировке документов.
При определении места хранения источника акции и мест хранения проведения акции необходимо учитывать, что текущая технология почтового обмена не разрешает управлять ценообразованием в базах данных, не подчиненных текущей. То есть, если схема проведения маркетинговой акции будет организована таким образом, что потребуется послать акт переоценки на исполнение в старшую базу данных и/или потребуется получить отклик об исполнении акта переоценки от старшей базы данных, то такое действие будет заблокировано почтовым модулем.
Текущая технология управления ценообразованием требует, чтобы место хранения источника акции было старшим по отношению к местам хранения проведения акции. Для контроля правильности документа создана функция проверки 162 «Корректность мест хранения маркетинговой акции». Функция имеет режим проверки «Всегда запрет».
При исполнении маркетинговой акции в нескольких базах данных наблюдение за фактом смены статуса маркетинговой акции не гарантирует того, что при видимом изменении статуса документа, акция действительно началась или действительно завершилась во всех местах ее проведения.
Для контроля полноты исполнения маркетинговой акции в таблицу отобранных документов добавлены колонки «Старт» и «Завершение». В колонках показывается количество созданных актов переоценки, соответственно, начала и завершения акции и общее количество актов, которое должно быть создано в ходе проведения акции.
Контроль над полнотой проведения акции имеет смысл только в такой базе данных, куда вернуться все акты переоценки, созданные в других базах данных при проведении маркетинговой акции. То есть это может быть старшая база данных или промежуточная база данных, в которой обслуживается место хранения источника акции. В подчиненных базах данных акты переоценки от других магазинов никогда не появятся, и в колонках всегда будет показываться неполное исполнение акции.
Если в документе «Маркетинговая акция» есть места хранения с локальным исполнением и эти места хранения не обслуживаются базой данных, в которой документ создан, то при отсутствии почтовой пересылки документа в требуемые базы данных, маркетинговая акция в этих местах хранения не состоится. При настройке почтового обмена надо внимательно следить за тем, чтобы правила почтовой рассылки были описаны правильно. Настраивать надо рассылку при смене статуса на «Принята», «Исполняется» и «Завершена». Отсылку при получении последних двух статусов необходимо настраивать независимо от того, выполняется ли периодическая процедура исполнения маркетинговых акций в подчиненной базе или нет. Смена статуса маркетинговой акции может произойти не только при наступлении времени начала или завершения акции, но и при принудительном ее старте и завершении, то есть как результат действия персонала. В этом случае возникает необходимость проинформировать о событии те подчиненные базы данных, которые обеспечивают локальное исполнение акции. Информирование осуществляется посылкой документа «Маркетинговая акция» с новым статусом.
При почтовом приеме маркетинговой акции делается проверка изменения статуса документа. В любом случае не разрешается понижать статус документа, если маркетинговая акция уже началась. Статус «Завершена» считается выше, чем статус «Исполняется», несмотря на то, что в фактически речь идет о статусе 0 «Заблокирован». После начала акции процесс не имеет обратного хода и акцию можно только завершить. Такое же поведение реализовано в интерфейсе торговой системы. Теперь запрещается понижать статус документа средствами интерфейса, если акция началась.
Почтовый прием маркетинговых акций в старшей и подчиненной базе реализован не одинаково. В подчиненной базе документ, пришедший из старшей, будет принят безусловно, за исключением описанного выше случая. И будет обработан, то есть в случае если статус документа изменяется в сторону повышения на «исполняется» и «завершена», то в подчиненной базе будут совершены действия по началу и завершению акции.
При приеме документа в старшую базу из подчиненной не разрешается принимать документ с понижением статуса, в том числе со статуса «Принята» до статуса «Черновик». Дополнительно при приеме документа делается проверка – не приведет ли повышение статуса маркетинговой акции в старшей базе к действиям по созданию актов начала или завершения акции. То есть проверяется, не являются ли какие-либо из мест хранения с локальным исполнением локальными для текущей базы данных и, если место хранение источника акции обслуживается текущей базой, то проверяется наличие в акции мест хранения с центральным исполнением.
В документ «Акт переоценки» добавлены информационные поля: «Кол-во основания», «План. кол-во переоценки», «План. сумма переоценки». Поля отображаются в таблице спецификации документа после включения их в диалоге «информационные поля», который вызывается кнопкой «Вид->Информационные поля».
В поле «Кол-во основания» отображается количество данного товара из документа - основания акта переоценки, если документ основание является приходной накладной, выходом из производства или контрактом, то есть является документом, который может быть использован для наценивания товара. Если акт переоценки создавался на основании других типов документов, это поле будет пустым.
В поле «План. кол-во переоценки» показывается количество товара, которое по текущему состоянию остатков должно было бы переоцениться, если бы акт переоценки исполнился в настоящий момент времени. Для уже исполненных актов переоценки содержание данного поля смысла не имеет.
В поле «План. сумма переоценки» показывается результат умножения планируемого количества переоцениваемого товара на разницу между старой и новой ценой. Значение старой цены берется из поля «Старая цена» акта переоценки. Для того чтобы значение старой цены было актуально необходимо пользоваться функцией «Обновить старую цену».
В документ «Складское требование» добавлена функция для округления количества затребованного товара до размера упаковки склада. Функция вызывается через меню «Функции - Округлить количество".
Функция позволяет округлить затребованное количество до минимального или максимального размера упаковки склада и в большую или меньшую сторону по выбору оператора.
Функция действует только для тех артикулов, для которых установлен признак «Складское требование в упаковках». Размер упаковки склада определяется по количеству, назначенному штриховому коду артикула, который, в свою очередь, имеет признак «Складское требование».
Для документа «Складское требование» реализованы две функции проверки:
\\ Внутренняя база данных модуля контроля цен была перенесена из оперативной памяти модуля в базу данных SMPriceChecker под управлением СУБД MySQL. Для эффективной работы модуля контроля цен база данных должна располагаться на том же компьютере, на котором функционирует служба модуля контроля цен. \\ Для установки внутренней базы данных программа установки торговой системы предлагает установить СУБД MySQL версии 4.017 и экземпляр базы данных. Если СУБД MySQL уже имеется на компьютере, процедура установки СУБД может быть пропущена. Проверка наличия СУБД осуществляется по наличию файла My.ini в каталоге операционной системы. \\ Если выбрана установка СУБД, процедура установки торговой системы запросит каталог для размещения MySQL. По умолчанию предлагается ставить в каталог C:\mysql. СУБД устанавливается с предварительно заданными пользователем «root» с паролем «masterkey», от имени которого можно производить действия по созданию и управлению базой данных. СУБД использует секцию \[mysqld\] файла My.ini для определения каталогов размещения и параметров экземпляров баз данных. \\ После установки СУБД производится регистрация и запуск службы mysql и генерация базы данных SMPriceChecker, если пользователь выбрал установку базы модуля контроля цен. Установка базы данных предлагается всякий раз при установке модуля контроля цен, независимо от того, была ли уже установлена СУБД ранее или нет. При установке базы данных, если база была установлена ранее, она будет предварительно удалена. Соответственно, после установки или модернизации модуля контроля цен необходимо обязательно проводить его полную загрузку со стороны торговой системы, чтобы заполнить базу актуальной информацией. \\ При установке базы данных необходимо указать имя пользователя и пароль, от имени которого будет проводиться генерация базы данных. Если СУБД была уже установлена ранее и не средствами программы установки торговой системы, то имя пользователя и пароль могут быть иными, чем заданные по умолчанию. В этом случае необходимо ввести правильные значения самостоятельно. \\ |
Добавлена функция проверки 161 «Точное соответствие прихода заказу поставщику». По умолчанию функция имеет режим «Запрет». Функция осуществляет проверку приходной накладной при смене статуса с черновик на принят в складом и при смене статуса с принят складом на принят центром.
Функция проверяет только приходные накладные, контрагент которых является собственным контрагентом и только приходные накладные, в основании которых имеется заказ.
При смене статуса с «Черновик» на статус «Принят складом» функция проверки сверяет количество и список артикулов в приходной накладной с содержанием заказа, стоящего в основании накладной. Функция срабатывает, если обнаруживается любое несовпадение количества прихода и заказа.
При смене статуса с «Принят складом» на «Принят центром» функция проверки сверяет цену полную в спецификации приходной накладной с ценами в заказе. Если в основании заказа имеется контракт, то проверка осуществляется с отклонением, разрешенным в контракте. Прочие атрибуты контракта: цены, вид цены, валюта контракта, во внимание не принимаются. Если в контракте отклонение не установлено, то считается, что цена прихода может быть любой, если в контракте установлена величина отклонения 0, то считается, что отклонение цены прихода от цены заказа не может превышать 1 копейки.