В процедуру установки торговой системы добавлено выполнение процедур установки компонентов Visual Studio , требующих регистрации в среде операционных систем Windows XP , Windows 2003 и выше, а именно файлов vcredist_x86.exe и msxml4qfe.exe.

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

Для работы драйвера касс УКМ4 более не требуется устанавливать драйвер MySQL JDBC . В текущей версии для взаимодействия с базой данных УКМ4 используются драйверы С++, которые устанавливаются программой установки торговой системы при выборе компонента «Модуль касс УКМ4 Супермаг». Драйвер поддерживает взаимодействие с базами данных MySQL версии 4.0, 5.0, а также кодировку ANSI и UTF 8.

Раздел «Активность покупателя».

В Торговую Систему добавлен раздел «Активность покупателя» для работы с одноименными объектами.

Объект «Активность покупателя» (тип объекта « AT ») был создан для сбора информации о покупательской активности держателей дисконтных карт. Объекты появились в версии 1.024.5, но не имели интерфейса для просмотра и ручной работы с ними. В предыдущих версиях объекты могли быть созданы автоматически на основании данных чеков одновременно с созданием кассовых документов (если это определено в настройках административного модуля) или с помощью функции «Расчет активности покупателей» в разделе «Кассовые чеки».

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

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

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

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

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

Для работы с объектами «Активность покупателя» созданы следующие функции:

- Удалить

- Разослать по почте

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

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

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

Раздел «Кассовые чеки». Поиск и отображение информации.

В разделе «Кассовые чеки» на странице отображения отобранных чеков внесены следующие изменения:

- В перечень полей спецификации чеков добавлены поля «Продавец-консультант» и «Штихкод». В поле «Продавец-консультант» выводится название продавца или его код в виде <код=0>, если код продавца отсутствует в перечне продавцов-консультантов для данного места хранения. Перечень продавцов-консультантов задается в разделе «Структура магазина/склада» для группы данных «Отделы» на странице «Персонал». В поле «Штихкод» выводится штриховой код товара, использованный для его идентификации при формировании чека. Поле остается незаполненным, если товар был продан без использования штрихового кода или если протоколом обмена с кассами не предусмотрен прием такой информации.

- В таблицу спецификации чека в ячейки колонки «Скидка» добавлена кнопка для детализации информации о сумме скидки по типам скидок.

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

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

Скидки. Статистика по дисконтным картам.

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

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

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

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

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

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

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

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

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

- Условия отбора данных о продажах – диапазон времени и группа товаров.

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

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

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

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

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

Управление датой и временем завершения.

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

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

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

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

Фильтр документов.

В краткий фильтр документов добавлены следующие атрибуты:

- дата начала акции

- дата окончания акции

- часть названия маркетинговой акции

- место хранения проведения акции

В подробный фильтр на страницу «Заголовок» добавлены атрибуты:

- диапазон дат начала акции

- диапазон дат окончания акции

- часть названия маркетинговой акции

- перечень мест хранения проведения акции

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

Контракты с поставщиками.

Фильтр документов. «Состояние».

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

Под состоянием документа подразумеваются следующие логические понятия:

- не принят

- ожидаемый

- действует

- завершен

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

«Не принят» означает, что статус контракта не позволяет ему действовать, независимо от дат действия контракта, то есть контракт имеет статус «Черновик» или «Заблокирован».

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

«Действует» означает, что контракт имеет статус «Принят» и текущая дата больше или равна дате начала действия контракта и меньше или равна дате окончания действия контракта. То есть текущая дата находится внутри диапазона дат действия контракта.

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

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

Генерация актов переоценки. Дата исполнения актов.

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

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

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

Заказы поставщикам.

Алгоритм автоматической генерации заказов.

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

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

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

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

Доработана функция пересчета количества заказа в рабочей среде процесса «Формирование заказа на базе контракта».

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

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

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

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

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

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

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

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

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

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

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

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

Зал – параметр «Зал» карточки складского учета – минимальное количество товара в торговом зале.

Поставка – параметр «Поставка» карточки складского учета – количество товара ожидаемого к поставке, то есть заказанного, но еще не поставленного.

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

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

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

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

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

Дополнительно создана функция проверки 176 «Заказываемое количество не кратно упаковке (процесс ORCP)». По умолчанию функция имеет режим «Запрет». Функция проверки срабатывает в начале работы функции генерации заказов до создания документов «Заказ поставщику».

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

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

Для описания перечня доступных типов алгоритмов создан справочник «Алгоритмы предложения заказа на базе контракта». В справочник вошло два алгоритма: «Эффективный» и «Регулярный». Название «Регулярный» присвоено алгоритму, созданному в версии 1.026.1. Название «Эффективный» присвоено новому алгоритму. Таблица справочника состоит из полей: идентификатор алгоритма, название и описание. Поле «Описание» содержит краткое описание алгоритма расчета предложения заказа:

Алгоритм «Регулярный»:

[Среднесуточная реализация] * ([Дата поставки] – [Дата заказа поставщику] + 1) – [Эффективный остаток]), где [Дата поставки] = [Дата заказа] + [Срок поставки (в днях) с учетом выбранных дней поставки]

Алгоритм «Эффективный»:

[Среднесуточная реализация] * ([Дата следующей поставки] – [Дата заказа поставщику] + 1) + [Зал] - [Эффективный остаток], где [Дата следующей поставки] = [Дата заказа] + [Срок поставки (в днях)] + [Частота заказа (в днях) с учетом выбранных дней поставки]

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

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

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

Функция проверки заказа на наличие действующего контракта.

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

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

Проверка осуществляется при смене статуса заказа с «Черновик» на «Размещен».

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

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

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

Проверка осуществляется при смене статуса заказа с «Черновик» на «Размещен».

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

Выход из производства.

Учет остатков в производстве при генерации актов производства.

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

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

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

Поле «Остатки в производстве».

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

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

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

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

- Прих. накл.: Понижение статуса документов, требующих корректировки

- Прих. накл.: Редактирование документов, требующих корректировки

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

В текущей версии добавлено функциональное право:

- Прих. накл.: Повышение статуса документов, требующих корректировки

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

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

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

Рецепты. Почтовая рассылка.

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

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

Карточки. Условия отбора документов на странице «Документы».

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

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

- Все производственные документы

- Товародвижение в производстве.

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

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

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

В разделе «Карточки складского учета» на странице «Цены» четыре колонки для настройки применения правил проверки цен в таблице видов цен заменены одной колонкой «Правила проверки цен».

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

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

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

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

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

Экспорт. Документы/проводки. ГТД.

В разделе «Экспорт» для типа экспортируемых данных «Документы/проводки» добавлена колонка «ГТД».

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

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

Администратор кассового сервера.

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

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

Функциональность администратора кассового модуля соответствует прежней функциональности со следующими отличиями:

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

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

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

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

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

4. Добавлено ведение журнала событий администратора кассового сервера и журнала событий службы кассового сервера. Журнал администратора имеет название « Sm . Cash . Admin < YYYYMMDDHH >. log », журнал службы – « CashServer < YYYYMMDDHH >. log », где

YYYYMMDDHH – год, месяц, день, час создания журнала. Файлы журналов размещаются в каталоге «…\Data» торговой системы.

Управление уровнем ведения журналов осуществляется в диалоге «Настройка общих параметров». Оба журнала управляются одновременно.

В среде операционных систем Windows Server 2003 (и старше) и Windows XP (и старше) в случае удаленной работы администратора кассового модуля, то есть когда служба кассового сервера расположена на одном компьютере, а администратор кассового модуля работает на другом компьютере, необходимо устанавливать разрешения на удаленной использование программ. На компьютере, где работает служба, необходимо помещать в список исключений брандмауэра программы Sm . ControlService . exe и Sm.Cash.Server.exe, а на компьютере, где работает администратор, - программу Sm . Cash . Admin . exe . Программу администратора кассового модуля Sm . Cash . Admin . exe предлагается поместить в список исключений автоматически при первом старте программы. Службы необходимо помещать в список вручную.

Драйвер касс УКМ4.

В текущей версии драйвер касс УКМ4 был изменен для одновременной поддержки разных версий СУБД MySQL , которая используется программой УКМ4 для обмена данными с Торговой системой. В результате изменений драйвер касс самостоятельно распознает версию и параметры базы данных обмена и автоматически осуществляет необходимые преобразования данных, в том числе, перевод данных из кодировки ASCII в кодировку UTF 8 и наоборот.

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

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

- В УКМ4 существует понятие скидки, как объекта, который связан с типом алгоритма скидки, единственным объектом применения скидки – типом дисконтных карт и условиями времени применения скидки.

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

1 – « Персональная скидка на классификатор (УКМ 2.x)» для передачи скидок по дисконтным картам, описанных в нотации УКМ2.

19 – «Скидка на классификатор и артикул» для описания скидок, предоставляемых при продаже конкретного артикула или артикула из заданной группы классификатора.

108 – «Скидка на чек по времени и сумме» для описания ступенчатых скидок по времени и сумме чека.

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

- ступенчатые скидки по времени и сумме чека,

- безусловные скидки по группе классификатора,

- скидка на артикул при покупке указанного количества,

- скидки по группам товаров для типа дисконтных карт и для отдельной дисконтной карты,

- скидки для артикула для типа дисконтной карты и для отдельной дисконтной карты,

- накопительные скидки для дисконтных карт по группам товаров,

- предложения скидок (бонусов) документа «Рекламные кампании».

Ступенчатые скидки по времени и сумме чека передаются через скидку УКМ4 с типом 108, безусловные скидки по группам классификатора и скидки на артикул за количество - через скидку УКМ4 типа 19 со ссылкой на пустой тип дисконтных карт. Скидки на дисконтные карты и типы дисконтных карт, описанные по правилам УКМ2, и накопительные дисконтные карты – через скидку УКМ4 типа 1.

Для типов дисконтных карт, описанных по правилам УКМ4, информация о скидках передается через скидку УКМ4 типа 19 со ссылкой на код типа дисконтных карт.

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

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

Документ проектировался до момента реализации системы скидок УКМ4 и не полностью совпадает с возможностями и нотацией скидок УКМ4.

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

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

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

Все предложения рекламной кампании передаются в УКМ4 как самостоятельные скидки и столько раз, сколько типов дисконтных карт, совместимых с УКМ4, указано в качестве участников рекламной кампании. Это связано с тем, что в документе «Рекламные кампании» каждое предложение может иметь собственное расписание применения в диапазоне дат рекламной кампании и может быть передано в УКМ4 на уровне иерархии не меньшем, чем скидка. Дублирование предложений рекламной кампании в виде нескольких скидок связано с тем, что скидка в УКМ4 может предоставляться только одному типу дисконтных карт.

Все варианты предложений передаются в УКМ4 как скидки типа 19 «Скидка на классификатор и артикул». Все скидки передаются для автоматического применения кассой. Все скидки передаются как пороговые.

Приоритет предложения рекламной кампании передается в УКМ4 как последовательность применения скидок. Приоритет рекламной кампании передается как группа скидок.

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

Тип пороговых значений в документе «Рекламные кампании» явным образом не задается и может быть описан комбинацией ограничений по сумме и по количеству. Поскольку УКМ4 требует однозначного указания одного варианта ограничений, то при выгрузке типа предложения рекламной кампании в УКМ4 тип пороговых значений устанавливается в значение «Суммовой», если поле «Минимальная сумма покупки» имеет значение больше 0 и «Количественный», если минимальная сумма покупки равна 0. Это означает, что в случае одновременного описания в документе «Рекламные кампании» ограничения и по сумме покупки и по количеству покупки, ограничение по количеству будет проигнорировано.

Ниже представлено соответствие типов предложений документа «Рекламная кампания» и единиц исчисления скидок УКМ4 для типа скидок 19 «Скидка на классификатор и артикул».

Тип предложения документа «Рекламная кампания»	Единица исчисления скидки УКМ4
«Скидка на позицию чека %»	«%%»
«Скидка на сумму чека %»	«% на классификатор(артикул)»
«Скидка на позицию чека»	«руб. на ед.»
«Скидка на сумму чека»	«руб. на классификатор (артикул)»

Условия предложений рекламных кампаний соответствуют строкам таблицы «классификатор/товар» описания скидки УКМ4 и описывает перечень товаров, наличие которых в чеке или позиции чека обуславливает применение скидки. Различие в структуре описания скидки УКМ4 и документа «Рекламные кампании» заключается в том, что ограничение по сумме покупки и величина скидки в документе «Рекламные кампании» задаются одинаковыми для всех групп товаров и артикулов, на которые эта скидка распространяется, и в условии предложения можно управлять только количеством товара, при покупке которого наступает условие предоставления скидки. При планировании скидок рекламной кампании необходимо учитывать следующую особенность поведения УКМ4: при анализе условий предоставления скидки кассовая программа ищет артикул сначала в списке артикулов, затем в группе классификатора артикула, затем в его старших группах по возрастанию старшинства и останавливает поиск при нахождении ближайшего условия. Например, если задано условие: группа «Все» - кол-во 0 - скидка 3%, группа «Кефир» - кол-во 3 - скидка 5%, то при покупке товара из группы «Кефир» в количестве меньшем 3, скидка не будет предоставлена вовсе, несмотря на наличие записи о скидке для группы «Все» без ограничения количества.

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

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

Прием чеков. Штриховые коды.

В процедуру приема информации о чеках, как закрытых, так и оперативных, добавлен прием штриховых кодов, использованных для идентификации товара при формировании позиции чека. Для хранения информации о штриховых кодах в таблицу SMCachCheckItems добавлено поле Barcode . В случае приема данных по протоколам УКМ2 это поле будет оставаться незаполненным.

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

Учет оснований товародвижения.

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

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

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

В административном модуле в разделе «База данных» для группы данных «Себестоимость» добавлена опция "Учитывать основания товародвижения для операций" с перечнем следующих операций:

- Возврат от покупателя

- Возврат поставщику

- Выбытие инвентаря

- Инвентаризация недостачи

- Перемещение между центральными складами

- Списание брака

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

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

Расчет себестоимости по методу «Средневзвешенная».

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

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

[Средняя цена периода усреднения] = ( [Сумма стоимости поставок в периоде] + [Сумма стоимости остатка на начало периода] ) / ( [Количество поставок в периоде] + [Количество остатка на начало периода] )

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

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

– если средняя цена получается отрицательной, то цена принимается равной 0.

– если сумма количеств равна 0, то цена также принимается равной 0.

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

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

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

Приход 10 шт. по 10 р., Образуется средняя стоимость 10 р./шт.
Расход 19 шт. Расход списывается по цене 10 р. за штуку.

Образуется отрицательный остаток –9 шт. суммой –90 р.

Следующий период:

Приход 10 шт. по 12 р. Остаток 1 шт.

Средняя цена нового периода усреднения = (120 – 90) / (10 – 9) = 30 р.

Значение цены обусловлено тем, что себестоимость отрицательных расходов 9 шт. равна 10 р., а компенсация отрицательного остатка приходом подразумевает, что их стоимость была 12 р., соответственно, разница сумм в 2х9=18 р. относится к положительному остатку от прихода.

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

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

Например:

Расход 10 шт. Расход списывается по цене 30 р.

Образуется отрицательный остаток –9 шт. стоимостью –270р.

Новый приход 10 шт. по цене 10р.

Новое значение себестоимости = (100-270)\(10-9) = -170

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

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

1. Если поставок в текущем периоде не было, то себестоимость периода равна себестоимости предыдущего периода.

Если поставки были:

2. Если стоимость остатка предыдущего периода неотрицательная и количество остатка неотрицательное, то стоимость нового периода усреднения рассчитывается по формуле:

[Средняя цена] = ( [Стоимость остатка] + [Стоимость поставок] ) / ( [Количество остатка] + [Количество поставок] )

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

[Средняя цена] = [Стоимость поставок] / [Количество поставок]

Следствия алгоритма:

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

Например:

Приход 10 шт. по 10 р.
Расход 19 шт.

Приход 10 шт. по 11 р.
Расход 10 шт.

Приход 10 шт. по 12 р.

Себестоимости движения и сальдо будут следующие:

Сальдо Остаток Себестоимость остатка

Приход +10 шт. +100 р. 100 10 100

Расход -19 -190 -90 -9 -90

Приход +10 +110 20 1 11

Расход -10 -110 -90 -9 -99

Приход +10 +120 10 1 12

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

Журнал расчета средневзвешенной себестоимости в закрытом периоде.

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

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

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

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

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

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

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

Журналы расчета остатков по местам хранения и остатков по приходам.

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

Использование журнала позволило сократить время открытия страницы «Статистика» раздела «Аналитика» административного модуля.

Бизнес-анализ.

Подведение итогов.

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

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

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

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

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

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

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

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

Сортировка данных по столбцам для задач типа «Кросс-таблица».

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

Фиксация колонок.

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

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

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

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

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

Фильтры.

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

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

- Фильтр по типам документов. Создан специальный фильтр по типам документов. Диалог фильтра позволяет отобрать требуемые типы документов из таблицы доступных типов. Таблица доступных типов содержит поля - код и название типа документа.

- Фильтр по системным операциям и фильтр по пользовательским операциям объединены в один фильтр - «Операция пользовательская. Код». В фильтре дается возможность выбрать необходимые операции, как системные, так и пользовательские из таблицы доступных операций. Таблица доступных операций содержит поля – код системной операции, код пользовательской операции, название операции.

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

Модель "Реализация в закупочных ценах".

Создана новая модель данных "Реализация в закупочных ценах". Модель данных аналогична модели "Реализация".

Модель позволяет получать следующую информацию:

- полная сумма / сумма без НДС установленной и неустановленной себестоимости реализации,

- полная сумма / сумма без налогов реализации,

- сумма дохода, полученного от реализации.

Отдельно можно получить данные о возвратах и продажах.

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

На основе модели «Реализация в закупочных ценах» созданы две системные задачи:

- Реализация в закупочных ценах по артикулам

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

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

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

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

Отчеты. Диалог выбора артикула.

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

Отчет «Реализация по поставщикам». Выбор мест хранений.

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

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

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