Перечень нововведений и исправленных ошибок в Супермаг + : Супермаг Плюс (Супермаг 2000)

Почтовый модуль.

Доверительная база данных.

К перечню типов баз данных к понятиям «старшая», «подчиненная», «равноправная», добавлен новый тип баз данных: «Доверительная база данных».

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

Доверительные базы данных необходимы для делегирования части полномочий или для дублирования информации старшей базы данных в одну или несколько баз данных, которые, в том числе, могут быть иного типа, чем база торговой системы «Супермаг». Использование доверительных баз данных позволит организовать объединение нескольких региональных сетей в федеральную сеть, где центральная база данных берет на себя только ряд функций старшей базы данных, например, ведение справочника товаров, с оставлением полных функций старшей базы данных региональному центру, например расчет себестоимости и закрытие периода. Также, использование доверительных баз данных позволяет организовать обмен со сторонними системами (SAP, Axapta, 1С) по специальным правилам обмена и, при необходимости, с делегированием части функций управления централизованными справочниками.

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

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

Раздельное описание правил рассылки для каждой доверительной базы данных сделано исходя из соображения, что доверительная база данных - это нестандартная база данных и таких баз не должно быть много и, в то же время, назначение и правила поведения каждой из доверительных баз данных в сети может быть разным.

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

Синхронизация объектов в базах данных.

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

Для управления синхронизацией и наблюдением за ходом процессов в интерфейс почтового модуля добавлена страница «Синхронизация». На странице отображается таблица, строка которой соответствует одному процессу сравнения или синхронизации.

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

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

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

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

Для конкретизации перечня сравниваемых объектов в мастере создания процесса можно задать ограничение по дате и / или месту хранения. Для документов также можно задать перечень номеров документов. При задании перечня документов условие отбора по другим критериям не действуют.

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

Для сокращения списка процессов в таблице просмотра создан фильтр процессов, в котором можно задать условие отбора записей.

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

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

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

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

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

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

Пересылка актов потерь в старшую базу данных.

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

При иных вариантах перехода документа в статус «заблокирован», например, при переходе с черновика на заблокирован, запрет приема документа с понижением статуса в старшую базу данных будет действовать по-прежнему.

Рассылка пользовательских операций.

В разделе «Настройка операций» реализована функция ручной рассылки пользовательских операций. Функция вызывается через пункт меню «Функции - Рассылка».

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

Автоматическая рассылка справочника не поддерживается.

Изменения функционала в версии 1.025.1


Маркетинговая акция.

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

Дата начала и завершения маркетинговой акции дополнены временем начала и завершения маркетинговой акции. По умолчанию, при создании маркетинговой акции, теперь будет предлагаться акция для следующего дня с 00:00 по 23:59.

Использование времени в сроке старта и завершения акции требует, чтобы расписание периодической процедуры исполнения маркетинговой акции было настроено с таким интервалом активности, при котором задержка между заданным временем исполнения акции и реальным временем исполнения была бы в допустимых пределах. Например, планируя акцию с точностью до часа, не следует задавать расписание работы процедуры один раз в день. Расписание следует задавать с интервалом как минимум в 10 минут.

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

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

Описание мест хранения и видов цен в маркетинговой акции.

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

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

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

Исполнение маркетинговых акций.

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

Локальное исполнение подразумевает, что акты переоценки начала и завершения маркетинговой акции для указанного места хранения будут создаваться только в той базе данных, которая обслуживает данное место хранения как локальное. Центральное исполнение маркетинговой акции для места хранения подразумевает, что акты переоценки для этого места хранения будут создаваться только в той базе данных, которая обслуживает место хранения - источник акции.

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

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

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

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

Контроль полноты исполнения маркетинговой акции.

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

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

Контроль над полнотой проведения акции имеет смысл только в такой базе данных, куда вернуться все акты переоценки, созданные в других базах данных при проведении маркетинговой акции. То есть это может быть старшая база данных или промежуточная база данных, в которой обслуживается место хранения источника акции. В подчиненных базах данных акты переоценки от других магазинов никогда не появятся, и в колонках всегда будет показываться неполное исполнение акции.

Почтовая рассылка и почтовый прием маркетинговых акций.

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

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

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

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

Акты переоценки. Информационные поля для контроля переоценки.

В документ «Акт переоценки» добавлены информационные поля: «Кол-во основания», «План. кол-во переоценки», «План. сумма переоценки». Поля отображаются в таблице спецификации документа после включения их в диалоге «информационные поля», который вызывается кнопкой «Вид->Информационные поля».

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

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

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

Складские требования. Контроль количества.

В документ «Складское требование» добавлена функция для округления количества затребованного товара до размера упаковки склада. Функция вызывается через меню «Функции - Округлить количество”.

Функция позволяет округлить затребованное количество до минимального или максимального размера упаковки склада и в большую или меньшую сторону по выбору оператора.

Функция действует только для тех артикулов, для которых установлен признак «Складское требование в упаковках». Размер упаковки склада определяется по количеству, назначенному штриховому коду артикула, который, в свою очередь, имеет признак «Складское требование».

Для документа «Складское требование» реализованы две функции проверки:
- 166 «Затребованное количество превышает доступный остаток склада». Режим по умолчанию «Предупреждение».
- 167 «Количество не кратно наименьшей упаковке склада». Режим по умолчанию «Предупреждение».

Обе функции проверяют содержание документа при переводе документа из статуса «Черновик» в статус «Принят к исполнению».

Функция 166 сверяет количество в складском требовании с доступным количеством склада. Под доступным количеством подразумевается текущее количество склада за вычетом количества потерь и зарезервированного товара.

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

Генерация заказов по контрактам с выбором мест хранения.

В мастер автоматической генерации заказов по контрактам добавлена страница выбора перечня мест хранения.

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

Подбор оснований в порядке поставок.

Функция простановки оснований товародвижения в расходных накладных имеет варианты поиска оснований по порядку поставок вперед или назад от установленных дат. Для этого варианта расчета дополнительно введено ограничение «Период, открытый для подбора оснований с …» заданной даты.

Ограничение устанавливается в административном модуле в разделе «Базы данных» на странице «Конфигурация» в папке «Документы». По умолчанию дата ограничения установлено в 01.01.1900.

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

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

Функция проверки «Дата документа больше текущей даты».

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

Функция позволяет для документов товародвижения – приходной накладной, расходной накладной, накладной на перемещение, расхода в производство, выхода из производства, возврата из производства проверять, что дата документа не больше текущей даты. Режимы проверки по разным типам документов могут устанавливаться раздельно.

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

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

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

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

Групповое изменение уровней складских запасов для списка мест хранений.

В функции групповой обработки артикулов для назначения уровней складских запасов: "Обработать - Изменение уровней складских запасов" раздела карточек складского учета реализован выбор нескольких мест хранения вместо одного в элементе диалога "для места хранения".

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

Полный перерасчет остатков.

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

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

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

Расчет себестоимости движения до первого прихода.

В расчете товародвижения в случае, если для движения товара, например, продажи, не удалось найти исходного прихода, делается расчет примерного значения себестоимости – значения неустановленной или неопределенной себестоимости. Расчет ведется по стоимости ближайшего предшествующего прихода.

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

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

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

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

Страница «Себестоимость» выделена из страницы «Прочее» в отдельную страницу. Страница «Прочее» получила название «Журналы».

Фильтр загрузки товаров на весы.

В алгоритм фильтра списка товаров, подготовленных для загрузки в весы, внесены следующие изменения:

Опция «неположительный остаток».

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

Опция "не было прихода - N дней".

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

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

Загрузка списка товаров из документов.

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

Функция "Срок годности".

Функция проставляет срок годности производных артикулов по сроку годности их базовых артикулов.

Почтовый модуль.

Доверительная база данных.

К перечню типов баз данных к понятиям «старшая», «подчиненная», «равноправная», добавлен новый тип баз данных: «Доверительная база данных».

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

Доверительные базы данных необходимы для делегирования части полномочий или для дублирования информации старшей базы данных в одну или несколько баз данных, которые, в том числе, могут быть иного типа, чем база торговой системы «Супермаг». Использование доверительных баз данных позволит организовать объединение нескольких региональных сетей в федеральную сеть, где центральная база данных берет на себя только ряд функций старшей базы данных, например, ведение справочника товаров, с оставлением полных функций старшей базы данных региональному центру, например расчет себестоимости и закрытие периода. Также, использование доверительных баз данных позволяет организовать обмен со сторонними системами (SAP, Axapta, 1С) по специальным правилам обмена и, при необходимости, с делегированием части функций управления централизованными справочниками.

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

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

Раздельное описание правил рассылки для каждой доверительной базы данных сделано исходя из соображения, что доверительная база данных - это нестандартная база данных и таких баз не должно быть много и, в то же время, назначение и правила поведения каждой из доверительных баз данных в сети может быть разным.

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

Синхронизация объектов в базах данных.

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

Для управления синхронизацией и наблюдением за ходом процессов в интерфейс почтового модуля добавлена страница «Синхронизация». На странице отображается таблица, строка которой соответствует одному процессу сравнения или синхронизации.

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

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

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

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

Для конкретизации перечня сравниваемых объектов в мастере создания процесса можно задать ограничение по дате и / или месту хранения. Для документов также можно задать перечень номеров документов. При задании перечня документов условие отбора по другим критериям не действуют.

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

Для сокращения списка процессов в таблице просмотра создан фильтр процессов, в котором можно задать условие отбора записей.

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

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

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

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

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

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

Пересылка актов потерь в старшую базу данных.

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

При иных вариантах перехода документа в статус «заблокирован», например, при переходе с черновика на заблокирован, запрет приема документа с понижением статуса в старшую базу данных будет действовать по-прежнему.

Рассылка пользовательских операций.

В разделе «Настройка операций» реализована функция ручной рассылки пользовательских операций. Функция вызывается через пункт меню «Функции - Рассылка».

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

Автоматическая рассылка справочника не поддерживается.

Модуль контроля цен.

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

Внутренняя база данных.

Внутренняя база данных модуля контроля цен была перенесена из оперативной памяти модуля в базу данных SMPriceChecker под управлением СУБД MySQL. Для эффективной работы модуля контроля цен база данных должна располагаться на том же компьютере, на котором функционирует служба модуля контроля цен.

Для установки внутренней базы данных программа установки торговой системы предлагает установить СУБД MySQL версии 4.017 и экземпляр базы данных. Если СУБД MySQL уже имеется на компьютере, процедура установки СУБД может быть пропущена. Проверка наличия СУБД осуществляется по наличию файла My.ini в каталоге операционной системы.

Если выбрана установка СУБД, процедура установки торговой системы запросит каталог для размещения MySQL. По умолчанию предлагается ставить в каталог C:\mysql. СУБД устанавливается с предварительно заданными пользователем «root» с паролем «masterkey», от имени которого можно производить действия по созданию и управлению базой данных. СУБД использует секцию [mysqld] файла My.ini для определения каталогов размещения и параметров экземпляров баз данных.

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

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

Администрирование модуля контроля цен.

В интерфейс администрирования модуля контроля цен добавлена страница «База данных» для управления параметрами соединения с внутренней базой данных. По умолчанию считается, что база данных установлена на локальном компьютере (localhost), доступна через порт 3306 и имеет название SmPriceChecker. Имя пользователя и пароль для соединения с базой данных значений по умолчанию не имеют и должны быть обязательно заданы. Если база данных устанавливалась с помощью программы установки торговой системы, их значения: «root» и «masterkey».

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

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

Удаленное администрирование.

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

Протокол обмена с торговой системой.

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

В файл данных о товарах «articles.0…m.txt» добавлено поле – код группы классификатора.

Файл скидок по группам классификатора DiscClass.txt заменен двумя файлами discclass.txt и discarticledk.0…m.txt. В файл discclass.txt выгружается информация о безусловных скидках на группу классификатора вида: код группы классификатора, процент скидки для группы товаров. В файл discarticledk.0…m.txt выгружаются скидки, определенные для отдельных артикулов, вида: артикул, процент скидки для артикула.
Файл скидок для дисконтных карт с типом карт для торгового зала discprice.0.txt заменен файлами discclassdk.txt и discarticledk.0…m.txt. В файл discclassdk.txt выгружаются скидки для групп товаров вида: код группы классификатора, процент скидки типа дисконтных карт, который определен как тип дисконтных карт для торгового зала (см. атрибуты места хранения в торговой системе) для группы товаров. В файл discarticledk.0…m.txt выгружаются скидки для дисконтных карт, определенные для отдельных артикулов, вида: артикул, процент скидки типа дисконтных карт, который определен как тип дисконтных карт для торгового зала (см. атрибуты места хранения в торговой системе) для артикула.

Значение величин скидок для групп товаров рассчитывается в торговой системе при выгрузке данных, с учетом наследования значений от старших групп классификатора при отсутствии значений для младших групп классификатора.

Сводный товарный отчет.

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

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

Товарный отчет по форме ТОРГ-29.

В состав торговой системы включен отчет «Товарный отчет по форме ТОРГ-29». Отчет включен в группу отчетов «бухгалтерские».

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

В отчете выводятся все оприходованные документы товародвижения для выбранного места хранения за заданный период с сортировкой по датам и номерам документов. Из рассмотрения исключены артикулы типа "инвентарь".

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

При выборе опции "показывать суммы в закупочных ценах" отчет выполняется по аналитическим таблицам (требуется предварительный расчет себестоимости). При выборе опции "без учета налогов" в отчете выводятся полные закупочные суммы. При отключенной опции "без учета налогов" выводятся закупочные суммы без НДС.

Условия исполнения (опции диалога):

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

Содержание отчета:

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

Подводятся итоги по типу операции (приход, расход).

Форма печати ТОРГ-12.

В печатную форму товарной накладной ТОРГ-12 внесены следующие изменения:

В итоговую часть печатной формы добавлены строки: «Главный (старший) бухгалтер», «Отпуск груза произвел», «М. П.»

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



****************************************
********* Изменения СМ 1.025.1 *********
****************************************

07.09.07 (№ 716) SP № 1

SMORA00002919. Если классификатор имеет не более пяти уровней вложенности, то выгрузка данных в формате УКМ2 сопровождалась появлением в журнале событий сообщений вида "General failure. Error messages follows. %1 %2 %3 %4 %5 %6 %7 %8". Исправлено.
SmUKMBaseDesk.dll, SmUKMDesk.dll, SmUKMCSVDesk.dll

07.09.07 (№ 715) SP № 1

Кассовый модуль. Исправлена ошибка выгрузки данных для кассы типа "Контроль цен" при отсутствии типа дисконтной карты для торгового зала:
ORA-01403: данных не найдено
ORA-06512: на "SUPERMAG.CASH", line 2118
CashPkgBody.sql, SmPriceCheckerDesk.dll

06.09.07 (№ 714) SP № 1

Акт переоценки. Реализовано округление новой цены до точности валюты вида цены из акта перед исполнением акта переоценки.
DocACPkgBody.sql

06.09.07 (№ 713) SP № 1

Модуль контроля цен. При сохранении на странице "Округление" поля "Количество знаков"= "X", при повторном входе на страницу значение поля отображается = "X,XX". Исправлено.
SmPriceChecker.exe

06.09.07 (№ 712) SP № 1

SMORA00002992. Акт переоценки. Заказ поставщику и от клиента. При смене места хранения в режиме редактирования документа с пустой спецификацией возникает ошибка "ORA-00936: отсутствует выражение" при выводе поля "Остатки". Исправлено.
SmDomDocsAC.dll, SmDomDocsOR.dll, SmDomDocs.dll

1.025.1 SP2
12.09.07 (№ 721) SP № 2

Административный модуль - База данных - Конфигурация - Себестоимость. Изменение параметра "считать нулевую неопр. с/с по буд. приходам" не будет требовать закрытия периода со сменой учетн. политики.
SysProc.sql

12.09.07 (№ 720) SP № 2

SMORA00002991. Кассовый модуль. Выгрузка в формате "УКМ4 Супермаг". Исправлен формат выгрузки величин нулевых скидок: вместо "0%" будет выгружаться "-0%".
ukm4_download.sql

12.09.07 (№ 719) SP № 2

SMORA00002964. Кассовый модуль. Выгрузка в формате "УКМ4 Супермаг". При выгрузке скидок по сумме чека для последней скидки удалена выгрузка времени окончания действия скидки.
ukm4_download.sql

12.09.07 (№ 718) SP № 2

SMORA00002996. Кассовый модуль. Исправлено: при выгрузке в формате "Контроль цен" не создается файл DiscArticleDk.0.txt, если не задан тип дисконтной карты для торгового зала.
SmPriceCheckerDesk.dll

12.09.07 (№ 717) SP № 2

Кассовый модуль. В формате "УКМ2 станд. TXT" выгружались свойства с длиной, не превышающей 10 символов. Теперь ограничение будет задаваться параметром "Макс. длина имени свойства артикула" ("Административный модуль - База данных - Конфигурация - Касса".
SmUniversal.dll, SMCashServer.exe, SmUKMBaseDesk.dll, SmUKMCSVDesk.dll

****************************************
********* Изменения СМ 1.025.1 *********
****************************************

20.09.07 (№ 724) SP № 3

SMORA00002998. Кассовый модуль. В формате "УКМ4 Супермаг" не выгружались заблокированные дисконтные карты накопительного типа в таблицу стоп-листа. Исправлено.
ukm4_download.sql

20.09.07 (№ 723) SP № 3

SMORA00003000. Карточки складского учета. Исправлена ошибка "Запись с ключом 0 не найдена в справочнике SMSTORELOCATIONS" при вызове диалога "Движение товара" на странице "Поставки", если в таблице приходов показан полностью закрытый приход.
SmDomCards.dll

20.09.07 (№ 722) SP № 3

SMORA00003003. Кассовый модуль. Исправлена выгрузка наименования товара в неверной кодировке для формата "УКМ2 Супермаг".
SmUKMDesk.dll, SmUKM4Desk.dll

****************************************
********* Изменения СМ 1.025.1 *********
****************************************

01.10.07 (№ 725) SP № 4

SMORA00003002. Расчет товародвижения. Исправлено падение производительности, происходящее после установки версии 1.025.1, если пользователь не совершал манипуляций с административной настройкой "Считать нулевую неопр. с/с по будущим приходам".

26.10.07 (№ 727) SP № 5

SMORA00003019. Реализовано исполнение акта переоценки с условием исполнения "при оприходывании перемещения в основании" при почтовом приеме накладной на перемещение в подчиненную базу со сменой статуса на принят полностью.
SMPostPkg.sql, DocACPkg.sql, DocProc.sql, SMPostPkgBody.sql, DocsPkgBody.sql, DocACPkgBody.sql

17.10.07 (№ 726) SP № 5

Повторное наценивание на основе контракта с поставщиком. Удаление ранее сгенерированных актов в статусе "Принят к исполнению" завершается ошибкой "Недопустимое значение статуса документа". Исправлено.
DocsModule.sql, SmDomDocsCO.dll

31.10.07 (№ 728) SP № 6

Разрешено создание и исполнение маркетинговых акций в месте хранения "Центральный офис". При проверке корректности акции, если источником акции является "Центральный офис", то все прочие мх проведения акции считаются подчиненными ему.
AucPkgBody.sql, Inspect3PkgBody.sql, DocTrg.sql, SmDomDocsMA.dll

Изменения функционала в версии 1.026
WEB сервисы торговой системы.

В версию включены WEB сервисы для доступа к функциям и данным торговой системы с использованием WEB обозревателей. Созданы функции и интерфейсы для обозревателей WiFi терминалов сбора данных, которые обслуживают процессы инвентаризации и приема товаров.

Компоненты WEB сервисов торговой системы состоят из компонентов WEB узла с именем «SMMobile», сервера приложений Супермага и администратора сервера приложений. Все компоненты рекомендуется устанавливать одновременно на один компьютер. В случае если сервер приложений и WEB узел IIS (Internet Information Services) устанавливаются на разных компьютерах, необходимо настроить параметры учетной записи для анонимного доступа IIS к WEB узлу (страница «Безопасность каталога» свойства узла «SMMobile»). Например, можно дать IIS права системного администратора сети при доступе к ресурсам узла SMMobile, что, в свою очередь, даст ему возможность обращаться к ресурсам другого компьютера локальной сети.

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

Предварительные требования для установки WEB узла.

На компьютере, на котором предполагается установить WEB узел, должен быть предварительно установлен .NET Framework версии 2.0 и IIS (Internet Information Services). IIS должен устанавливаться после установки .NET Framework. Установка IIS производится в разделе установок компонентов операционной системы Windows. IIS предпочтительно устанавливать в серверных версиях OC Windows. Если IIS установлен в среде OC Windows 2003, необходимо в настройках расширения WEB служб (управление компьютером, оснастка IIS) разрешить использование ASP.NET v 2.0.50727.

Если торговая система была установлена до установки IIS, то после установки IIS необходимо повторно установить компонент «WEB компоненты» из раздела установки «сервер приложений».

Администрирование сервера приложений.

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

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

Функции администрирования сервера приложений.

1. Регистрация базы данных.

Сервер приложений должен взаимодействовать с базой данных для выполнения необходимых бизнес функций. Для установления соединения с базой данных ее необходимо зарегистрировать, то есть указать имя и, при необходимости, настроить параметры работы с базой данных (см. ниже). Имя пользователя и пароль не задаются, поскольку эти данные должны быть получены от пользователя системы в момент начала его работы.

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

2. Время пассивности сессии.

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

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

Интерфейс не позволяет установить время пассивности меньше 60 секунд, поскольку при более коротком времени ожидания работа пользователя становится затруднительной.

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

3. Настройка общих параметров.

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

Ведение журнала. Журнал ведется на компьютере сервера приложения в подкаталоге AppServer его рабочего каталога. Имя журнала, например, AppServer2007110115.log, где 2007110115 – дата его создания.

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

Порт канала. Номер порта, по которому идет обмен между IIS и сервером приложений. Изменять номер порта можно только при одновременном изменении номера порта сервера (см. ниже).

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

3. Настройки WEB приложения.

Интерфейс позволяет управлять настройками WEB приложения, которые хранятся в файле WEB.Config IIS. В случае изменения параметра «Порт сервера» необходимо одновременно изменить параметр «Порт канала» сервера приложения.

Управление активными сессиями сервера приложений.

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

WiFi терминалы сбора данных.

Терминалы сбора данных с операционными системами Windows CE или Windows CE.NET (Windows Mobile) и WiFi интерфейсами доступа в локальную сеть имеют возможность использовать WEB сервисы торговой системы для получения доступа к разделам торговой системы в процессах инвентаризации товара и приема товара (см. ниже). Использование WEB сервисов торговой системы подразумевает, что отображение и ввод информации пользователем будет происходить с использованием WEB обозревателя. Это отменяет необходимость предварительной установки клиентской части на мобильное устройство и обеспечивает полную независимость мобильного устройства от версии торговой системы.

Доступ к тому или иному разделу WEB сервисов осуществляется через разные URL адреса. Каждому разделу соответствует свой адрес. Для быстрого старта раздела необходимо создать ярлык WEB обозревателя на рабочем столе с указанием адреса страницы раздела в свойстве «Объект» ярлыка, например:
"C:\Program Files\Internet Explorer\IEXPLORE.EXE" /SMMobile\WEBPages\Inventory.aspx

где
ComputerName – имя компьютера, на котором расположен IIS,
SMMobile\WEBPages – имя WEB узла и каталога WEB страниц
Inventory.aspx – имя страницы раздела.

Особенности работы с WEB сервисами.

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

WEB обозреватель не может использоваться для накопления значительных объемов информации, соответственно, данные, вводимые пользователем, сохраняются в торговой системе немедленно после их передачи от обозревателя серверу приложений Супермаг. В случае разрыва соединения все ранее введенные данные, за исключением данных последней страницы, будут доступны после повторного входа в раздел. Разрыв соединения может произойти как при сбоях в сети WiFi, так и из-за истечения времени ожидания активности пользователя.

Инвентаризация WiFi терминалом сбора данных.

URL адрес раздела:

/SMMobile\WEBPages\Inventory.aspx

где ComputerName – имя компьютера, на котором расположен IIS.

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

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

Сервис предоставляет следующие интерфейсы:

1. Страница авторизации пользователя.

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

2. Условие поиска документа - накопителя данных о результатах инвентаризации.

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

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

3. Выбор документа

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

4. Просмотр детальной информации заголовка и выбор дальнейшего режима работы.

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

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

5. Режим инвентаризации.

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

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

6. Режим просмотра спецификации.

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

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

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

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

Прием товаров WiFi терминалом сбора данных.

URL адрес раздела:

/SMMobile\WEBPages\ WayBillIn.aspx

где ComputerName – имя компьютера, на котором расположен IIS

Раздел предназначен для проведения этапа приема товара: сбора информации о фактически поставленном товаре и проверке соответствия его количества заказанному количеству. Прием может проводиться только по товарам со штриховыми кодами. Если штриховой код у товара отсутствует, регистрация информации о нем невозможна. Также невозможно зарегистрировать товар, штриховой код которого отсутствует в торговой системе.

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

Сервис предоставляет следующие интерфейсы:

1. Страница авторизации пользователя.

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

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

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

3. Список заказов.

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

4. Выбор или создание приходной накладной.

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

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

5. Просмотр заголовка приходной накладной, выбор режима работы.

Показывается детальная информация из заголовка документа: номер, дата, поставщик, место хранения, номер заказа в основании накладной.

Далее можно перейти в режим приема товара или режима спецификация.

6. Режим приема товара.

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

При превышении заказанного количества выдается сообщение, и регистрация приема такого товара не разрешается.

7. Режим спецификации.

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

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

В режиме спецификации можно зафиксировать завершение этапа приема товара, то есть можно зарегистрировать документ, переведя его в статус «Принят на складе».

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

Документ «Рекламные компании».

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

Структура документа «Рекламные компании» предназначена для описания следующих категорий информации о маркетинговом мероприятии:
- Бенефициары или участники акции, то есть субъекты, на которых нацелено мероприятие. Это могут быть все посетители, владельцы дисконтных карт, владельцы купонов и т.д.
- Условия предоставления бенефиций или условия предложения (даты, время, дни недели, купленные товары, их количество, сумма покупок и т.д.)
- Бенефиции или предложения (скидки, бонусы и т.д.).

Управление маркетинговыми мероприятиями с помощью документа «Рекламные компании» подразумевает взаимодействие с программой ККМ, на которую возлагается задача конечного исполнения мероприятия. Сам документ «Рекламные компании» не производит каких-либо действий и служит только источником информации для загрузки данных в программу ККМ.
Соответственно, возможности маркетингового мероприятия определяются совокупными возможностями документа «Рекламные компании» и исполняющей программы, то есть программы ККМ.

В текущей версии в качестве исполняющей программы может выступать только программа УКМ4. При использовании протоколов обмена с кассами типа УКМ2 информация о рекламных компаний не может быть передана в кассовую программу.

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

Для документа Рекламные Компании определено понятие приоритета. Приоритет рекламной компании необходим в том случае, когда пересекается время действия двух или более компаний.

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

Типы дисконтных карт. Описание для УКМ4.

В описание типов дисконтных карт введено описание параметров типов дисконтных карт в терминах УКМ4. Параметры типа дисконтных карт для УКМ4 в интерфейсе отделены от параметров для УКМ2 для лучшего понимания предназначения этих атрибутов.

УКМ4 поддерживает работу с типами дисконтных карт как в своем формате, так и формате УКМ2. Важным является то, что описание типа не может быть передано в УКМ4 одновременно в обоих форматах. Формат УКМ4 является более строгим по сравнению с форматом УКМ2 и не всякое описание типа первоначально созданное как описание карт для УКМ2 может быть приведено к типу УКМ4. В частности, отдельные дисконтные карты типа не имеют право иметь собственные значения скидок, отличные от скидок типа. С другой стороны, описание в формате УКМ4 позволяет передавать в кассовую программу больше информации о способе предоставления скидки, например, указывать время предоставления скидки.

Дополнительная информация о способе и условиях предоставления скидки в описании типа дисконтных карт не может быть определена, поскольку не является атрибутом типа дисконтных карт. Эта информация задается в разделе «Рекламная компания» (см. выше).

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

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

В случае если тип дисконтных карт, определен как совместимый с УКМ4, и содержит дисконтные карты, не подпадающие под описание типа, то при использовании протокола УКМ4, такие карты будут выгружены через таблицы, предназначенные для описания дисконтных карт типа УКМ2.

Драйвер MySQL JDBC для работы с УКМ4.

Для корректной работы драйвера касс УКМ4 необходимо установить драйвер MySQL JDBC из файла mysqlJdbc.jar. Файл расположен в каталоге mysql-connector-java-1.026 каталога дистрибутивов.

Установка драйвера производится запуском следующей командной строки.

Для загрузки драйвера в базу:

%ORACLE_HOME%\bin\loadjava.bat -user <имя пользователя>/<пароль>@<имя БД> -o -r -g public -s %JDBC_HOME%\mysqlJdbc.jar
Например: C:\Ora81\bin\loadjava.bat –user sys/qqq@db026i2 –o –r –g public –s c:\mysqlJdbc.jar


Для удаления драйвера из базы:

%ORACLE_HOME%\bin\dropjava.bat -user <имя пользователя>/<пароль>@<имя БД> %JDBC_HOME%\mysql-connector-java-2.0.14-bin.jar
Например: C:\Ora81\bin\dropjava.bat –user sys/qqq@db026i2 c:\mysql-connector-java-2.0.14-bin.jar

Справочник «Процессы».

В перечень системных справочников добавлен справочник «Процессы».

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

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

Короба.

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

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

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

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

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

Связь короба со штриховым кодом разрывается при объявлении штрихового кода недопустимым, поскольку как только теряется связь короба с артикулом, свойство артикула в атрибутах короба становится бесконтрольным. Обработка связи «штриховой код – короб» осуществляется по такому же принципу, как при удалении штрихового кода, то есть: если этот штриховой код был единственным, связанным с коробом, то при объявлении его недействительным, короб удаляется.

Описание короба для временных артикулов запрещено. Короба могут создаваться только в старшей базе данных.

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

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

Почтовая рассылка информации о коробах происходит при ручной отсылке штриховых кодов либо артикулов, как рассылка объекта типа «BX». Отдельного интерфейса для ручной рассылки конкретного короба не создано. Реализована автоматическая рассылка короба при его создании, изменении, удалении.

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

Смена вида свойства у артикула разрешается только в том случае, когда у артикула нет ни одного штрихового кода с коробом или значением свойства.

Прием и отгрузка товара в коробах.

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

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

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

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

Создание нового процесса приема поставки и повторный вход в ранее начатые процессы реализовано в разделе приходных накладных как вызов функции «Прием поставки». В разделах расходные накладные и накладные на перемещение это функция «Формирование отгрузки».

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

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

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

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

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

При вводе артикула вручную в мастере ввода можно указать количество товара в упаковке, но нельзя указать количество упаковок. Количество упаковок можно ввести в строке спецификации.

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

Собранные данные можно просматривать в порядке ввода (основной режим), с группировкой по одинаковым штриховым кодам (по упаковкам), и с группировкой по артикулам. При выборе режима группировки происходит объединение строк с одинаковым штриховым кодом (группировка по упаковкам) или с одинаковым артикулом (группировка по артикулам), количество введенного товара при этом, соответственно, суммируется.

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

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

Автоматическое создание калькуляций.

В разделе «Калькуляции» создана функция «Автоматическое создание калькуляций». Для доступа к функции должности необходимо предоставить функциональное право «Калькуляция: Автоматическое создание калькуляций».

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

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

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

На этапе формирования перечня рецептов процесс может быть прерван и затем продолжен в произвольный момент времени.

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

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

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

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

Доступ к просмотру перечня мест хранений и к просмотру документов.

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

В текущей версии возможности по управлению правами должности расширены следующим образом:

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

Ограничение просмотра мест хранений действует на все элементы интерфейса, в которых показывается перечень мест хранения. Основное назначение данного ограничение – упрощение работы персонала со списками мест хранения. Ограничение на просмотр мест хранения не влечет запрета на работу с объектами, связанными с этими местами хранения. Если пользователь отберет каким-либо образом документ, с запрещенным для просмотра местом хранения, то данный документ будет доступен ему для работы, и в заголовке документа будет отображаться запрещенное место хранения. Это же касается отчетов. При выборе опции «Все места хранения», данные в отчет будут выводиться независимо от того, какие места хранения запрещены к просмотру.

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

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

Ставка НДС в контрактах с поставщиками.

В спецификацию документа «Контракт с поставщиками» добавлено поле «НДС поставщика, %». Поле предназначено для регистрации значения ставки НДС товара такой, какой ее видит поставщик на момент заключения контракта.

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

Создана функция проверки 165 «Несовпадение ставок НДС поставщика и карточки товара». Функция по умолчанию имеет режим «Предупреждение». Функция осуществляет проверку содержания документа при переводе документа в статус «Принят». Если поставщик не является плательщиком НДС, проверка совпадения ставок не осуществляется.

Электронные весы.
Загрузка в весы полного/ короткого названия товара.

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

Опция влияет на все виды весов, представленных в торговой системе.

Исключение из загрузки товаров с не установленным флагом «Грузить в весы».

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

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

Условие проверки не показывается в перечне условий фильтра, поскольку не предполагается управлять этим условием. Это необходимо учитывать при анализе колонки «Грузить в весы».

Расчет среднесуточной реализации по ассортиментам.

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

Экспорт. Выгрузка валютных данных документа.

В сценарий экспорта "Документы / проводки" добавлены новые поля: "Валютный документ", "Вид валюты", "Курс валюты", "Цена в валюте", "Сумма в валюте". Последние два поля не экспортируются для документов производства в режиме "Ингредиенты". Под курсом валюты понимается курс из документа за единицу валюты документа.

Аналитическая база. Перенос валютных данных документа.

При переносе в аналитическую базу документов товародвижения дополнительно будут переноситься поля: "Валютный документ", "Курс валюты", "Множитель курса валюты". В связи с этим изменением после установки версии необходимо обязательно произвести очистку и полный перенос данных в аналитическую базу.

Товарный отчет по форме ТОРГ-29. Опция «показывать контрагентов».

В диалог запуска отчета «Товарный отчет по форме ТОРГ-29» добавлена опция «показывать контрагентов». Если опция не выбрана, отчет работает так же как раньше. Если опция выбрана, в отчете выводятся названия контрагентов документов, кроме расходных накладных на списание, для них вместо названия контрагента будет выведено слово "списание", и кассовых документов, для них будет выведено слово "касса".

Отгрузочные листы. Печатная форма «отгрузочная спецификация».

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

**************************************
********* Изменения СМ 1.026 *********
**************************************

13.11.07 (№ 732) SP № 1

Почтовый модуль. Повышена надежность работы с FTP-транспортом.
Sm.Post.Server.exe, Sm.Post.Filters.Standard.dll, Sm.Post.Filters.Xml.dll, Sm.Post.Filters.dll, Sm.Post.VirtualPackage.dll, Sm.Post.Transports.dll, Sm.Core.dll
**************************************
********* Изменения СМ 1.026 *********
**************************************

26.11.07 (№ 739) SP № 2

SMORA00003039. Почтовый модуль. Добавлено дополнительное условие на автоматическую рассылку короба: короб не будет рассылаться для неактивных карточек.
SmDomCards.dll

26.11.07 (№ 738) SP № 2

Экспорт. Исправлена ошибка "cannot insert NULL into TTEXPORTACC.CURRENCYTYPE" при выгрузке поля "Вид валюты" в типе экспорта "Документы/проводки" для аналитической базы, если в выгрузку попадают документы закрытого периода.
AccountsTable.sql

26.11.07 (№ 737) SP № 2

SMORA00003031. Наценивание. Ранее после исполнения акт переоценки отсылался в БД, для которой в почтовом модуле прописано старшее место хранения. Теперь после исполнения акт будет принудительно отсылаться в старшую БД.
DocACPkg.sql, DocACPkgBody.sql

26.11.07 (№ 736) SP № 2

Рецепт. В стандартной печатной форме увеличена точность вывода коэффициента цены и процента потерь: с 2 до 4 знаков после запятой.
pf_recipe.rep

26.11.07 (№ 735) SP № 2

Новые заказные печатные формы "Калькуляционная карта" и "Технологическая карта".


26.11.07 (№ 734) SP № 2

Административный модуль. Добавлен системный параметр "Учитывать потери промежуточной обработки в рецепте" в раздел "База данных - Конфигурация - Документы".
SMToolsCore.dll

26.11.07 (№ 733) SP № 2

Рецепт. Добавлены поля <Кол-во после 1-й обработки> и <Потери 1-й обработки>.
DocSpec.sql, DocCAPkg.sql, DocCAProc.sql, DocCAPkgBody.sql, SmDomDocsPR.dll

26.11.07 (№ 744) SP № 2

SMORA00003055 SMORA00003054 Администратор сервера приложений. Исправлена ошибка блокировки доступа к настройкам общих параметров в случае неверного пути к файлу web.config. При неверном пароле сообщение заменено на "Ошибка открытия соединения"
Sm.BusinessServer.dll, Sm.Sm2000Admin.exe, Sm.Sm2000DbServer.dll, Sm.AppServerObjects.dll, Sm.Database.dll, Sm.BusinessConstructor.dll, Sm.Core.dll, Sm.Sm2000AppServer.exe, Sm.Core.Client.dll, Sm.Bridge.dll, Sm.Core.Server.dll, Sm.AppServerInterfaces.dll

26.11.07 (№ 743) SP № 2

Прайс-чекер. 1) Настройки для обработки входящих штриховых кодов по типам работали неверно для Штрих-М. 2) Сообщение об отсутствии штрихкода перенесено на уровень предупреждения. 3) Реализовано сохранение последнего выбора устройства при повторном старте.
SmPriceChecker.exe, SMSrvCtl.dll

26.11.07 (№ 742) SP № 2

Административный модуль. Исправлено самопроизвольное прерывание расчета товародвижения в производстве с сообщением <Расчет прерван пользователем>.
SMRepAdmin.dll

26.11.07 (№ 741) SP № 2

SMORA00003036. Рецепт. Добавлено ограничение на ввод значений в поле "Коэффициент цены". Теперь туда можно ввести значения от 0 до 100. Ранее можно было ввести некорректные значения, что выявлялось при попытке сохранить их в БД.
SmDomDocsPR.dll

26.11.07 (№ 740) SP № 2

SMORA00003035. Калькуляция. Подписи в мастере автоматического создания калькуляций изменены с "Расход в производство" на "Расход на производство", в соответствии с официальным названием типа документа.
SmDomDocsPR.dll

13.11.07 (№ 732) SP № 1

Почтовый модуль. Повышена надежность работы с FTP-транспортом.
Sm.Post.Server.exe, Sm.Post.Filters.Standard.dll, Sm.Post.Filters.Xml.dll, Sm.Post.Filters.dll, Sm.Post.VirtualPackage.dll, Sm.Post.Transports.dll, Sm.Core.dll

13.11.07 (№ 731) SP № 1

Товарный отчет в закуп. ценах. В отчете с группировкой по местам хранения (МХ) не показывались МХ с кол-вом на начало периода, прихода и расхода за период = 0, но с сальдо на начало периода в закуп. ценах != 0. Исправлено.
tovrep_zakupprice.rep

13.11.07 (№ 730) SP № 1

Реализован интерфейс с весами Bizerba.
SCSWScale.dll, SmScaleBizerba.dll, Hardware.sql

****************************************
********* Изменения СМ 1.025.1 *********
****************************************

14.01.08 (№ 754) SP № 8

Исправлено: сбор статистики по таблице SMOfficeLog в Oracle 9i завершался ошибкой ORA-00600: код внутр. ошибки, аргументы: [12830], [SUPERMAG], [SMSTAFF], [], [], [], [], [].
OfficePkgBody.sql

14.01.08 (№ 755) SP № 8

Модуль контроля цен. Исправлено: 1) ошибка обработки шаблона Shuttle - %NAME=хх, строки с числами после команд включаются в команду 2) ошибка распознавания весового штрихового кода.
SmPriceChecker.exe

05.12.07 (№ 746) SP № 8

SMORA00002756. Сличитель. ведомость, Инвентаризацион. опись. Исправлено: при вводе через мастер производного артикула типа "размер" с ненулевым кол-вом формируется строка с нулевым значением суммы.
SmDomDocsRL.dll, SmDomDocsIL.dll

05.12.07 (№ 745) SP № 8

Почтовый модуль. Повышена надежность работы с FTP-транспортом.
Sm.Post.Server.exe, Sm.Post.Filters.Standard.dll, Sm.Post.Filters.Xml.dll, Sm.Post.Filters.dll, Sm.Post.VirtualPackage.dll, Sm.Post.Transports.dll, Sm.Core.dll

05.12.07 (№ 749) SP № 8

SMORA00003034. Накладные. Исправлено: невозможно через портативные терминал задать нулевое кол-во для ранее введенного артикула с ненулевым кол-вом.
SmDomDocs.dll

05.12.07 (№ 748) SP № 8

SMORA00003030. Заказ поставщику. Исправлено: невозможно через мастер задать нулевое кол-во для ранее введенного артикула с ненулевым кол-вом.
SmDomDocsOR.dll, SmDomDocsCO.dll, SmDomDocsPR.dll, SmDomDocsSO.dll

05.12.07 (№ 747) SP № 8

Сличительн. ведомость. Исправлено: 1) неверно отображается кол-во "Без свойства" в колонке "Ожидаемое количество", 2) добавление или замещение кол-ва с учетом значений свойств при использовании терминала сбора данных приводит к искажению информации.
SmDomDocsRL.dll, SmTerminal.dll

31.10.07 (№ 729) SP № 7

Изменен протокол работы FTP транспорта для обмена с большим перечнем FTP серверов.
Sm.Post.Transports.dll

**************************************
********* Изменения СМ 1.026 *********
**************************************

26.03.08 (№ 762) SP № 4

Ускорен отбор документов в разделах документов на больших объемах данных.
OfficePkgBody.sql

26.03.08 (№ 763) SP № 4

Акты переоценки. Реализован сброс времени предполагаемого исполнения в значение "00:00" при изменении пользователем значения поля "Предполагаемая дата исполнения".
SmDomDocsAC.dll