[ОТВЕТИТЬ]
20.08.2007 18:16
Владимир
 
Почтовый модуль.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Автоматическая рассылка справочника не поддерживается.
11.09.2007 15:01
stalker
 
Изменения функционала в версии 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
17.09.2007 11:33
Mtirt
 
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
21.09.2007 16:41
Владимир
 
****************************************
********* Изменения СМ 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
05.10.2007 12:16
orekhov
 
****************************************
********* Изменения СМ 1.025.1 *********
****************************************

01.10.07 (№ 725) SP № 4

SMORA00003002. Расчет товародвижения. Исправлено падение производительности, происходящее после установки версии 1.025.1, если пользователь не совершал манипуляций с административной настройкой "Считать нулевую неопр. с/с по будущим приходам".
31.10.2007 15:42
Mtirt
 
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.2007 15:43
Mtirt
 
31.10.07 (№ 728) SP № 6

Разрешено создание и исполнение маркетинговых акций в месте хранения "Центральный офис". При проверке корректности акции, если источником акции является "Центральный офис", то все прочие мх проведения акции считаются подчиненными ему.
AucPkgBody.sql, Inspect3PkgBody.sql, DocTrg.sql, SmDomDocsMA.dll
29.11.2007 11:06
stalker
 
Изменения функционала в версии 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
24.01.2008 12:56
orekhov
 
****************************************
********* Изменения СМ 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
27.03.2008 10:11
Владимир
 
**************************************
********* Изменения СМ 1.026 *********
**************************************

26.03.08 (№ 762) SP № 4

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

26.03.08 (№ 763) SP № 4

Акты переоценки. Реализован сброс времени предполагаемого исполнения в значение "00:00" при изменении пользователем значения поля "Предполагаемая дата исполнения".
SmDomDocsAC.dll
18.04.2008 19:11
orekhov
 
**************************************
********* Изменения СМ 1.026 *********
**************************************

07.04.08 (№ 766) SP № 5

SMORA00003127. Исправлено: наценивание наборов не работало на Oracle 10g, если на БД не установлен 4 патчсет.
RevalACPkgBody.sql

07.04.08 (№ 765) SP № 5

SMORA00003121. Наценивание. Исправлено: если наценивание происходит сегодня, то при расчете не учитываются налоги для карточек, к которым на сегодня привязана налоговая группа, но привязана и еще одна налоговая группа, действующая с завтрашнего дня.
RevalACPkgBody.sql

07.04.08 (№ 764) SP № 5

Добавлен заказной отчет "Товарный отчет ТОРГ-29 в розничных ценах".
SmRepCustom.dll

07.04.08 (№ 767) SP № 5

Исправлено: задание на расчет среднесуточной реализации могло завершаться ошибкой "ORA-06503: PL/SQL: Function returned without value" при указании в условиях расчета более 70 групп классификатора товаров.
SQLFilterPkgBody.sql
16.05.2008 12:07
Mtirt
 
1.026.1 сп1
07.05.08 (№ 777) SP № 1

Почтовый модуль. Исправлена ошибка приема команды на разрешение обрезки "ORA-20003: Попытка заблокировать объект дважды".
Sm.Post.DbLoader.dll

30.04.08 (№ 776) SP № 1

SMORA00003150. Документы. Исправлена ошибка чтения списка документов, если пользователь исключил из интерфейса вывод поля места хранения документа.
SmDomDocsAC.dll, SmDomDocsPA.dll, SmDomDocsPR.dll, SmDomDocsAD.dll, SmDomDocsSR.dll, SmDomDocsSO.dll, SmDomDocsRO.dll, SmDomDocsRL.dll, SmDomDocs.dll, SmDomDocsOR.dll, SmDomDocsME.dll, SmDomDocsMA.dll, SmDomDocsIL.dll, SmDomDocsCS.dll, SmDomDocsCO.dll, SmDomDocsCC.dll, SmDomDocsBI.dll, SmCashChecks.dll

30.04.08 (№ 775) SP № 1

Карточки складского учета. Исправлено появление ошибки "ORA-00933: неверное завершение SQL-предложения" на закладке "Поставщики" на Oracle 8i при параметре CURSOR_SHARING, установленном в FORCE.
SmDomCards.dll

30.04.08 (№ 774) SP № 1

SMORA00003159. Карточки складского учета. Увеличен размер поля для ввода значения наценки в фильтре на странице "Наценки".
SmDomCards.dll

30.04.08 (№ 773) SP № 1

Печать этикеток. Исправлено падение программы при ее закрытии, если в ходе рабочей сессии вызывалась печать этикеток.
SmLabelPrinter.dll

30.04.08 (№ 772) SP № 1

SMORA00003158. Ускорен отбор товаров для загрузки в весы при установленном фильтре "Не было приходов за последние N дней" и/или "Неположительный остаток".
HardwarePkgBody.sql

30.04.08 (№ 771) SP № 1

SMORA00003160. Кассовые документы. Исправлено: расчет статистики по налогам завершался ошибкой "ORA-01403: данные не найдены" на базе Oracle 10g.
SmTxBody.sql

30.04.08 (№ 770) SP № 1

SMORA00003161. Рекламные кампании. Исправлено: проверка 116 срабатывала, если предложение содержит несколько одинаковых типов предложений с одинаковыми условиями и одним и тем же временем действия, но разной минимальной суммой покупок.
DocPAProc.sql, InspectPkgBody.sql

30.04.08 (№ 769) SP № 1

Отчет "Реестр накладных". Исправлено: суммы по таре в итоговой секции отчета всегда выводятся = 0.
reestr_nacl.rep

30.04.08 (№ 768) SP № 1

SMORA00003128. Модуль контроля цен. Исправлено: если в реестре отсутствует ключ HKEY_LOCAL_MACHINE\SOFTWARE\Service Plus\SuperMag2000\Categories\PriceChecker\DB, сервис не использует значения по умолчанию для доступа к файлу БД.
SmPriceChecker.exe
30.05.2008 18:51
konst
 
На FTP Сервис+ появился 2 сервис пак к версии 1.026.1
(как это не странно - но нет последней части архива)
список исправлений:

26.05.08 (№ 784) SP № 2

Исправлено: при подъеме БД до версии 1.026.1 происходил отзыв прав должностей на раздел "Остатки".
ResForInit.exe

26.05.08 (№ 785) SP № 2

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

23.05.08 (№ 783) SP № 2

SMORA00003167. Накладные на перемещение. Восстановлена возможность просмотра журнала истории документа, пропавшая в версии 1.026.1.
SmDomDocs.dll

23.05.08 (№ 782) SP № 2

SMORA00003169. Кассовые документы. Исправлено: не отбирались для показа документы "Возвраты по кассе". Ошибка внесена в сервис паке 1 к версии 1.026.1.
SmDomDocsCS.dll

23.05.08 (№ 781) SP № 2

SMORA00003165. Исправлено: инициализация БД с 1.026 до 1.026.1 завершалась ошибкой "ORA-00439: Не задействована функциональная возможность: Function-based indexes" на Oracle Standard Edition до версии Oracle 9.2.x.
ResForInit.exe, Documents.sql

23.05.08 (№ 780) SP № 2

Кассовый модуль. Выгрузка в формате "УКМ2". Ранее таблицы 23, 25, 28, 29 выгружались всегда. Теперь 23, 25 будут выгружаться при настройке "Налоги для арт-ов: Ставка налога", а 28, 29 - "Налоги для арт-ов: Налог. группа". Изменение влияет на обмен с УКМ4.
SmUKMDesk.dll, SmUKMCSVDesk.dll, SmUKMBaseDesk.dll

23.05.08 (№ 779) SP № 2

SMORA00003166. Заказ поставщику. Исправлено: если добавить список артикулов в редактируемый документ, то обнуляется кол-во ранее добавленных артикулов, если они присутствуют в этом списке.
SmDocLib.dll

23.05.08 (№ 778) SP № 2

SMORA00003168. Сличительные ведомости. Исправлено: импорт строк в редактируемый документ завершался ошибкой "PLS-00306: ошибочно число или типы аргументов при обращении к SMDOCUPDSPECDRAFTPSRL".
SmUniversal.dll, SMComKernel.dll
07.08.2008 11:28
orekhov
 
****************************************
********* Изменения СМ 1.026.1 *********
****************************************

17.07.08 (№ 791) SP № 3

Контрагенты. Реализована ручная рассылка контрагента в доверительные базы данных.
SMCompanies.dll


17.07.08 (№ 790) SP № 3

Карточки складского учета. Реализована ручная рассылка карточки в доверительные базы данных.
SmDomCards.dll, SMPostPkgBody.sql

17.07.08 (№ 789) SP № 3

SMORA00003186 Карточки складского учета. Исправлено: при копировании карточки, для которой был установлен флаг "Ингредиент", новая карточка создается без флага "Ингредиент".
Cards.sql, CardsPkg.sql, SmDomCards.dll

17.07.08 (№ 788) SP № 3

SMORA00003182 Процесс формирования заказа на базе контракта. Исправлено: если в спецификации процесса много строк, то обновлении спецификации такого процесса завершается ошибкой: PLS-00123: программа слишком велика.
SmDomDocsOR.dll

17.07.08 (№ 787) SP № 3

SMORA00003180 Процесс формирования заказа на базе контракта. Исправлено: расчет среднесуточной реализации с опцией "Диапазон расчета: последние N дн." или "За все время продаж" всегда возвращает 0.
SaleRatePkg.sql, SaleRatePkgBody.sql, DocProc.sql, SmDomDocsOR.dll

17.07.08 (№ 786) SP № 3

SMORA00003173. Бизнес-анализ. Исправлено: не формируется системная задача "Сумма реализации по группам товаров с детализацией по местам хранения" при наличии фильтра по МХ или артикулам и опцией "Учитывать только дни реализации=нет".
AnalyticsPkgBody.sql
05.09.2008 20:26
orekhov
 
****************************************
********* Изменения СМ 1.026.1 *********
****************************************

29.08.08 (№ 792) SP № 4

Добавлен заказной отчет "Товарный отчет ТОРГ-29 в розничных ценах ("Торнадо")".
SmRepCustom.dll

29.08.08 (№ 793) SP № 4

Почтовый модуль. Исправлено: прием пакета, в котором содержится команда на удаление маркетинговой акции, завершается ошибкой: PLS-00306: wrong number or types of arguments in call to 'SMDOCDELETEMA'.
AuctionProc.sql
30.09.2008 14:27
Mtirt
 
****************************************
********* Изменения СМ 1.026.2 *********
****************************************

25.09.08 (№ 796) SP № 1

SMORA00003201. Рабочее место продавца-консультанта. Краткое наименование валюты теперь во всех местах интерфейса будет считываться из БД, а не задаваться жестко "р".
WebUnit/Respublika_SalesConsultant/…

25.09.08 (№ 795) SP № 1

SMORA00003203. Инвентаризация / прием товара через WiFi. Реализовано распознавание весового штрихового кода.
Sm.BusinessServer.dll, Sm.AppServerInterfaces.dll, Sm.Objects.dll, WEB/…

24.09.08 (№ 794) SP № 1

Администратор. Добавлена возможность производить расчет товародвижения без расчета себестоимости в производстве.
SmRepAdmin.dll, SmRepLauncher.dll, SmRepParam.dll, prod_zakupprice.rep, CreateTblFifo.sql, FIFOPkg.sql, TblFifoTrg.sql, FIFOBody.sql, FRemainsPkgBody.sql, RepToolsPkgBody.sql
21.01.2009 23:40
orekhov
 
****************************************
********* Изменения СМ 1.026.3 *********
****************************************

19.01.09 (№ 822) SP № 3

Отчет "Оборот предприятия". Исправлена неверная сортировка данных по датам.
oborot.rep

19.01.09 (№ 821) SP № 3

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

19.01.09 (№ 823) SP № 3

Отчет "Прайс-лист". Исправлена неверная сортировка данных по группам товаров.
pricelist_bar.rep, pricelist.rep

16.01.09 (№ 819) SP № 3

Кассовый сервер. Исправлено: выгрузка на кассу типа дисконтных карт, совместимых с УКМ4, требовало обязательного задания префикса типа УКМ2.
Cash.sql, CashPkgBody.sql

16.01.09 (№ 820) SP № 3

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

16.01.09 (№ 818) SP № 3

Кассовый сервер. Реализован прием оперативных чеков с пустым артикулом в позиции чека из УКМ4: такой артикул будет замещен "Артикулом продажи по сумме" (задаётся в административном модуле).
SmUKMCSVDesk.dll, SmUKMDesk.dll

15.01.09 (№ 817) SP № 3

Карточки складского учета. Ускорен отбор данных на закладке "Документы".
DocSpec.sql, SmDomCards.dll

14.01.09 (№ 816) SP № 3

Почтовый сервер. Реализована поддержка разбора списка файлов каталога от нового типа FTP-сервера в FTP-транспорте.
Sm.Post.Transports.dll

14.01.09 (№ 815) SP № 3

Кассовый сервер. Исправлены ошибки перекрытия результатов расчета накопительных скидок при одновременной работе кассового модуля и почтового приема активности покупателя.
Cash.sql, CashProc.sql, CashPkgBody.sql

26.12.08 (№ 814) SP № 2

Кассовый сервер. Драйвера "УКМ2 станд. TXT" и "УКМ2 Супермаг". Исправлено: если в оперативном чеке есть артикул, которому назначено свойство и который продан без указания значения свойства, он попадает в Супермаг со значением свойства вида "|3#NOSIZE|".
SmUKMCSVDesk.dll, SmUKMDesk.dll

25.12.08 (№ 812) SP № 2

Административный модуль. Реализованы просмотр и редактирование параметра "Грузить в кассу УКМ2 полное название товара" в разделе "База данных - Касса".
SmToolsCore.dll

25.12.08 (№ 813) SP № 2

Кассовый сервер. Драйвера "УКМ2 станд. TXT" и "УКМ2 Супермаг". Реализована работа с кассой, имеющей кодировку ANSI. Для настройки этой возможности добавлен параметр "Административный модуль - База данных - Касса - Кодировка в УКМ2".
SmUniversal.dll, SmToolsCore.dll, SmCashServerLib.dll, SmUKMDesk.dll, SmUKMCSVDesk.dll, SmUKMBaseDesk.dll

23.12.08 (№ 810) SP № 2

SMORA00003212. Кассовый сервер. Драйвер "Prestige". В журнал сервера больше не будет помещаться сообщение "Драйвер кассы не поддерживает режим оперативной сводки".
SmCashServerLib.dll

23.12.08 (№ 811) SP № 2

SMORA00002997. Структура магазина/склада. Реализована проверка на несовпадение каталогов загрузки, закрытия и оперативной сводки при настройке каталогов кассы.
SmDomShop.dll

23.12.08 (№ 806) SP № 2

Новый заказной отчет "Отчет по продажам".
RepToolsPkgBody.sql, SmRepCustom.dll

23.12.08 (№ 808) SP № 2

Кассовый сервер. Реализован прием пустого артикула в позиции чека из УКМ4: такой артикул будет замещен "Артикулом продажи по сумме" (задаётся в административном модуле).
SmUniversal.dll, SmToolsCore.dll, SmCashServerLib.dll, SmUKM4Desk.dll, SmUKMDesk.dll, SmUKMCSVDesk.dll, SmUKMBaseDesk.dll

23.12.08 (№ 807) SP № 2

Классификатор товаров. Исправлено: изменение параметров расчета среднесуточной реализации для какой-либо группы товаров приводит к удалению операций расчета, назначенных другим группам товаров.
CardsPkg.sql

23.12.08 (№ 805) SP № 2

Сводный товарный отчет. Увеличена ширина колонки "Себестоимость" в секции "Наличная реализация с выделением налога с продаж".
tovreport_sum.rep

23.12.08 (№ 809) SP № 2

SMORA00002616. Кассовый сервер. Драйвера "УКМ2 станд. TXT" и "УКМ2 Супермаг". Проверка наличия каталога записи и его доступности для записи/чтения/удаления файла перенесена в начало активизации процедуры выгрузки.
SmCashServerLib.dll

05.12.08 (№ 804) SP № 1

Заказы поставщику. Исправлено: в мастере генерации заказа на основе контракта не показываются контракты, если для поставщика существуют контракты с большим числом мест поставки (более 170).
DocTrg.sql

02.12.08 (№ 802) SP № 1

SMORA00003219. Драйвер касс УКМ4. Исправлено: не выгружается мин. цена для артикулов с фикс. ценой или участвующих в марк. акциях, если в адм. модуле в разделе "Ценообразование" установлен атрибут "скидки запрещены для артикулов".
SmUKM4Desk.dll, CashPkg.sql, CashPkgBody.sql

02.12.08 (№ 799) SP № 1

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

02.12.08 (№ 800) SP № 1

Накладные. Исправлена ошибка пересчёта цен накладных с гос. регулированием для базы в формате "Беларусь".
SMComKernel.dll

02.12.08 (№ 801) SP № 1

SMORA00003103 Драйвер касс УКМ4. Исправлена ошибка при выгрузке типа ДК с несколькими диапазонами "Duplicate key or integrity constraint violation message from server".
SmUKM4Desk.dll

02.12.08 (№ 803) SP № 1

Драйвер касс УКМ4. Исправлено: избыточные сообщения об ошибках при отказе в соединении с БД MySQL.
SmUKM4Desk.dll
09.02.2009 20:16
orekhov
 
03.02.09 (№ 826) SP № 4

Бизнес-анализ. Исправлено: если в фильтре вызвать диалог установки фильтра по артикулу и далее вызвать диалог выбора номера документа, то попытка выбора в этом диалоге контрагента завершается ошибкой "таблица не существует".
AnalyticsModule.sql

28.01.09 (№ 824) SP № 4

Накладные без метки гос. регулирования (Беларусь). Исправлено: в режимах округления "Цена без налогов" и "Сумма без налогов" простановка цен из основания дает нулевые значения цен, за исключением цены производителя.
SmCOMKernel.dll, DocsModule.sql, DocsPkgBody.sql

28.01.09 (№ 825) SP № 4

Генерация складского требования в упаковках. Исправлена ошибка "ORA-02290: нарушено ограничение целостности SLCSPECPACKSNPACKS", возникающая, если после распределения по упаковкам остается требование на неупакованное количество < 1.
StorePkgBody.sql
24.02.2009 04:39
BR
 
Цитата:
Vovantus На сиплюшном ФТП, кажись, ещё в пятницу появился 5 сервис-пак для версии 1.026.3. Но описания нет Есть у кого-нить информация что в нём нового?
12.02.09 (№ 829) SP № 5

Закрытие периода. Исправлено: после появления в версии 1.026.3 настройки расчета товародвижения "учитывать основания товародвижения для операций" при закрытии периода перестали учитываться основания по товародвижению.
SmRepAdmin.dll

12.02.09 (№ 830) SP № 5

Расчет себестоимости в производстве. Исправлено: в аналитическую базу док-тов производства не переносились производственные док-ты, полностью закрытые с точки зрения склада, и, следовательно, эти док-ты не принимали участие в расчете с/с в производстве.
FIFOTransferBody.sql, SmRepAdmin.dll, RepAdminModule.sql

12.02.09 (№ 827) SP № 5

Акты переоценки. Исправлено: при длине номера документа больше 9 символов печать документа завершалась ошибкой "REP-1401: 'cf_title_in_pageformula': Произошла фатальная ошибка PL/SQL".
act_change_price.rep

12.02.09 (№ 828) SP № 5

Наценивание. Исправлено: если для места хранения задан флаг "Цены ЦС синхронизированы с этим складом", то принятие акта переоценки по артикулам такого спецсклада приводило к зацикливанию программы.
DocACPkgBody.sql
09.03.2009 12:36
Kryukov
 
27.02.09 (№ 833) SP № 7
Накладные (Беларусь). Исправлено: при копировании цен из одного документа в другой должно пропускаться поле "Розничная цена".
DocsPkgBody.sql
27.02.09 (№ 834) SP № 7
Накладные (Беларусь). Исправлено: вызов функций "Генерация списаний по нормам отходов", "Заполнение положительными / отрицательными остатками" завершалось ошибкой "ORA-00942: таблица или представление пользователя не существует".
DocsModule.sql
19.02.09 (№ 832) SP № 6
Расходные накладные (Беларусь). Исправлено: вызов функции "проставить основания" завершался ошибкой "ORA-20005: Перед обновлением объект необходимо заблокировать".
DocProc.sql, DocCOProc.sql
19.02.09 (№ 831) SP № 6
Приходные накладные (Беларусь). Исправлено: создание накладной на основании сличительной ведомости завершалось ошибкой "ORA-00942: таблица или представление пользователя не существует".
DocsModule.sql
26.03.2009 10:50
Kryukov
 
****************************************
********* Изменения СМ 1.026.4 *********
****************************************
19.03.09 (№ 837) SP № 1
Закрытие периода со сменой учетной политики. Исправлено: исключена возможность запуска закрытия периода без указания партнера.
SMRepAdmin.dll
19.03.09 (№ 836) SP № 1
Обрезка базы. Исправлено: доступ к кнопке "Обрезать" недоступен, если на дату самого раннего периода на складе, закрытого со сменой учетной политики, нет закрытого периода в производстве.
SMRepAdmin.dll
16.03.09 (№ 835) SP № 1
Обрезка базы в производстве. Исправлено: будут удалены записи о последних и/или нераспределенных приходах в таблице FFProdAvailIncome_ на дату <= дате обрезаемого периода. Ранее удалялись только записи на дату < дате обрезаемого периода.
PCloseBody.sql, PClose.sql
20.04.2009 09:38
Kryukov
 
****************************************
********* Изменения СМ 1.026.4 *********
****************************************
13.04.09 (№ 851) SP № 3
Почтовый обмен. Разрешен прием по почте некоторых типов документов (контракты, калькуляции, рецепты и т.п.) с датой, попадающей в обрезанный период.
DocProc.sql, PCloseBody.sql
13.04.09 (№ 850) SP № 3
Отчет "Движение в производстве по себестоимости". Возвращена колонка "Разница", убранная в версии 1.026.4.
prod_zakupprice.rep, SMREPORT.HLP
13.04.09 (№ 849) SP № 3
Закрытие периода. Исправлено: если создание бухгалтерских справок (расходов) завершалось ошибкой, программа фиксировала успешное начало закрытия периода.
RemainsPkgBody.sql, FRemainsPkgBody.sql, FRemInPkgBody.sql, PCloseBody.sql
13.04.09 (№ 848) SP № 3
Исправлено: расчет статистики "Остатки в закупочных ценах по местам хранения / приходам" завершался ошибкой "ORA-06502: буфер символьных строк слишком маленький", если в расчете использовались данные бухгалтерских справок и кол-во этих док-ов было велико.
CreateTblFifo.sql, FRemainsPkgBody.sql, FRemInPkgBody.sql
31.03.09 (№ 844) SP № 2
Расчет себестоимости на складе. Расширено описание, выдаваемое системой при обработке ошибки формирования данных для выгрузки в файл.
SMRepAdmin.dll
31.03.09 (№ 843) SP № 2
Экспорт "Документы (OLAP)". Исправлено: в процедуре отбора документов реализованы фильтры по видам артикулов, по виду собственности товара, по виду платежа.

31.03.09 (№ 842) SP № 2
Экспорт "Документы (OLAP)". Исправлено: из диалога описания проводки убрана кнопка "Ингредиенты", сделана недоступной кнопка "Тип суммы", в списке доступных операций оставлены только операции товародвижения.

31.03.09 (№ 841) SP № 2
Экспорт. Исправлено: описание проводок теперь будет привязано не к сценарию экспорта, а к типу экспорта, которому разрешены проводки и который включен в текущий сценарий.

31.03.09 (№ 840) SP № 2
Экспорт. Реализован новый тип экспорта: "Документы/проводоки в производстве".
SmAccounts.dll, AccountsTable.sql, Accounts.sql, AccountsBody.sql, ExportProc.sql
31.03.09 (№ 839) SP № 2
Справочники "Доп. характеристики товара/склада/контрагента/ДК" и "Метки документов". Исправлено: начиная с версии 1.026.2 вместо типа характеристики/метки "Число" стала выводиться фраза "Неподдерживаемая установка в Панели управления...".
SmLibraryBase.dll
31.03.09 (№ 838) SP № 2
Установка сервис пака. При ручном запуске программы установки сервис пака к торговой системе добавлен вывод диалога с номером устанавливаемого обновления.
10.07.2009 10:25
konst
 
1.026.3 сервис пак №10


09.07.09 (№ 886) SP № 10

Акты переоценки. Возвращен диалог для расчета "на лету" торговой наценки.
SmDomDocsAC.dll, DocACPkg.sql, DocACPkgBody.sql, DocACProc.sql

03.07.09 (№ 880) SP № 10

Печатная форма "Счет-фактура". В режиме "без служебной информации" удален вывод номера транспортной накладной, строк "все суммы:..." и номер счета-фактуры, выводящихся над таблицей спецификации, строк "итого", "итого сумма НДС", "итого сумма без НДС".
nacl_inout_factura.rep

03.07.09 (№ 881) SP № 10

Приходные и расходные накладные. В диалог печати счета-фактуры и ТОРГ-12 добавлена опция "без налога (НДС)" При ее выборе в печатной форме вместо ставки НДС 0% будут выводиться слова "Без налога (НДС)".
nacl_inout_factura.rep, nacl_inout.rep, SmDomDocs.dll

03.07.09 (№ 885) SP № 10

Сличительные ведомости. Исправлен импорт излишков / недостачи из сличительной ведомости в другой документ при наличии в сличительной ведомости детализации по свойствам.
DocRLPkg.sql, DocRLPkgBody.sql, DocRemotePkgBody.sql

03.07.09 (№ 883) SP № 10

Печатная форма "Счет-фактура" приведена в соответствие с Постановлением Правительства РФ от 26.05.2009 № 451: реализован вывод короткого названия контрагента-продавца в дополнение к основному названию.
nacl_inout_factura.rep

03.07.09 (№ 882) SP № 10

Контрагенты. Добавлен новый атрибут контрагента "Короткое название".
SMCompanies.dll, Clients.sql, ClientsTrg.sql, SmPostTableLoad.sql
10.07.2009 10:27
konst
 
1.027.0 сервис пак №2

09.07.09 (№ 887) SP № 2

Исправлена ошибка "Раздел «Код=xxx» не установлен" при переходе между разделами и при вызове функций, запрашивающих другие разделы (например, печать ценников из списка док-тов), пользователями, не имеющих прав на запись в реестр HKEY_LOCAL_MACHINE.
SmCOMKernel.dll, SmLibaryUser.dll

09.07.09 (№ 888) SP № 2

Карточки складского учета. Исправлено: не был доступен для выбора список значений дополнительных характеристик на странице "Описание" в версии 1.027.
SmRefsLib.dll
10.03.2010 16:48
Владимир
 
Вот. Выход после 14 марта.

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


Установка отчетов, скомпилированных Oracle Report Builder 11. 1
Использование отчетов Oracle Report Builder 11 и Oracle Report Builder 6i. 1
Особенности выполнения отчетов при использовании удаленного сервера отчетов. 2
Документ «Бухгалтерская справка». 2
Генерация бухгалтерских справок при закрытии периода. 3
Отчет «Расчёт сумм коррекции себестоимости движения товаров». 4
Закрытие складского требования при отправке накладной на перемещение. 4
Подбор сертификатов соответствия для артикулов с незаданным сроком годности. 5
Контракт с поставщиком. Мастер функции «Создать новую редакцию контракта». 6
Ордер на доставку. Ручной ввод спецификации. 6
Бизнес-анализ. 6
Модели «Движение артикула за период», «Реализация в закупочных ценах за период», «Реализация за период». 6
Группы полей «Остаток на начало периода», «Остаток на конец периода». 7
Группы полей «Цены для кассы», «Цены учетные». 7
Поле «Тип и номер документа». Переход к выбранному документу. 7
Функция проверки 1 «Документ содержит неактивные карточки». 8
Функция проверки 92 «Обязательное указание сорта». 8
Функция проверки 155 «Цена контракта больше цены предыдущего контракта». 8
Функция проверки 192 «Запрет понижения статуса складского требования при наличии принятых накладных на перемещение». 8
Функция проверки 188 «Корректность документов "Маршрутный лист"». 8
Раздел «Мониторинг состояния базы данных». 8
Перечень исправленных ошибок. 8

Установка отчетов, скомпилированных Oracle Report Builder 11.

Подготовлена программа установки отчетов, скомпилированных в среде Oracle Report Builder 11. Программа установки выполнена отдельно от программы установки торговой системы для того, чтобы избежать путаницы при установке отчетов Oracle Report Builder 6i для локального исполнения и отчетов Oracle Report Builder 11 для исполнения в среде Oracle Fusion Middleware 11g.

Локальное исполнение отчетов Oracle Report Builder 11 в текущей версии не предусматривается в связи с тем, что данные отчеты не могут выполняться при работе с базой данных Oracle 8i. Данные отчеты предполагается выполнять только с использование сервера отчетов Oracle Fusion Middleware 11g.

Заявленная ранее возможность выполнения отчетов в среде Oracle AS Reports & Forms services 10g поддерживаться не будет, в связи с наличием в этой версии сервера отчетов непреодолимых проблем при формировании отчетов в формате PDF с использованием кириллических шрифтов.

Установка отчетов Oracle Report Builder 11 содержит полный набор стандартных отчетов, печатных форм и ценников. Отличие нового комплекта отчетов от отчетов Oracle Report Builder 6i заключается только в отсутствии в отчетах графиков.

Пользовательские отчеты и ценники могут быть скомпилированы в среде Oracle Report Builder 11 только при явном запросе.

Для использования отчетов в среде Oracle Fusion Middleware 11g необходимо надлежащим образом настроить сервер отчетов. Инструкция по настройке сервера отчетов прилагается к программе установки.

Использование отчетов Oracle Report Builder 11 и Oracle Report Builder 6i.

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

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

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

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

При работе базового модуля с использованием сервера приложений и при удаленном исполнении отчетов необходимо следить за тем, чтобы синоним базы данных, описанный в файле tnsnames.ora на компьютере сервера приложений и в установках Oracle Fusion Middleware 11g на компьютере сервера отчетов в точности совпадали. В противном случае отчеты выполняться не будут.

Особенности выполнения отчетов при использовании удаленного сервера отчетов.

При удаленном выполнении отчетов в текущей версии доступен вариант получения отчетов в окне интернет-браузера в формате PDF, HTML или страница HTML. Для просмотра отчета в формате PDF на компьютере должен быть установлен Acrobat Reader. Прямая печать отчета недоступна и может быть выполнена средствами Acrobat Reader или интернет-браузера.

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

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

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

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

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

Документ «Бухгалтерская справка».

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

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

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

Документ имеет тип «BR», статусы «Черновик», «Заблокирован» и «Принят». Поле «Комментарий» документа предназначено для описания причины и обоснования сумм коррекции.

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

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

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

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

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

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

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

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

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

В поле «Комментарий» документов заносится описание причины коррекции:
- нулевое количество - ненулевая сумма
- отрицательное количество - положительная сумма

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

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

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

Отчет «Расчёт сумм коррекции себестоимости движения товаров».

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

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

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

Закрытие складского требования при отправке накладной на перемещение.

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

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

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

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

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

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

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

- Закрывать складские требования прошлых дней
- Закрывать складские требования полностью отгруженные
- Закрывать складские требования после первой отгрузки

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

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

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

В текущий алгоритм функции «Подбор номеров сертификатов/ГТД» для документов «Расходные накладные», «Накладные на перемещение» и «Счет-фактура кассовых чеков» в алгоритм подбора сертификатов по документам «Сертификат соответствия» внесено следующее изменение:

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

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

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

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

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

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

Контракт с поставщиком. Мастер функции «Создать новую редакцию контракта».

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

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

Ордер на доставку. Ручной ввод спецификации.

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

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

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

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

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

Модели «Движение артикула за период», «Реализация в закупочных ценах за период», «Реализация за период».

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

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

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

Прежние модели получили названия «Движение артикула по документам», «Реализация по датам», «Реализация в закупочных ценах по датам».

Группы полей «Остаток на начало периода», «Остаток на конец периода».

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

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

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

Группы полей «Цены для кассы», «Цены учетные».

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

В состав группы полей «Цены для кассы» входят поля: «Цена», «Наценка %», «Минимальная наценка %», «Максимальная наценка %», «Идет маркетинговая акция (да/нет)».

В состав группы полей «Цены учетные» входят поле «Цена».

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

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

Поле «Тип и номер документа». Переход к выбранному документу.

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

Поле добавлено в стандартные задачи «Движение артикула в производстве» и «Основания товародвижения по FIFO» вместо полей «Тип документа» и «Номер документа».

Функция проверки 1 «Документ содержит неактивные карточки».

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

Функция проверки 92 «Обязательное указание сорта».

Действие функции проверки распространено на документы «Складское требование» и «Заказ поставщику» при смене статуса документов с «Черновик» на «Принят к исполнению» / «Размещен». Строки с названием указанных выше типов документов добавлены в таблицу диалога «Детализация функции проверки».

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

Изменено название функции проверки 155. Функция получила название: «Цена контракта больше цены предыдущего контракта более чем на 20%». Алгоритм и поведение функции остались без изменения.

Функция проверки 192 «Запрет понижения статуса складского требования при наличии принятых накладных на перемещение».

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

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

Функция проверки 188 «Корректность документов "Маршрутный лист"».

Содержание функций проверки 188 «Количество загруженного товара должно быть не больше количества доступного для загрузки» и 189 «Количество возвращенного товара должно быть не больше количества загруженного» объединено в одну функцию проверки 188 «Корректность документов "Маршрутный лист"». Режим работы функции остался прежним «Всегда запрет».

В функцию188 добавлена проверка наличия в документе типа транспортного средства при смене статуса документа с «Черновик» на «Принят к исполнению».

Раздел «Мониторинг состояния базы данных».

В составе системы восстановлен раздел «Мониторинг состояния базы», который был временно изъят в версии 1.027. Для старта раздела необходимо выбрать пункт меню «Окно-> Мониторинг состояния базы»

Раздел восстановлен в прежней функциональности.

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

- Карточки складского учета. Медленное открытие закладок «Остатки» и «Заказ» в случае ограничения прав пользователя на просмотр единиц мест хранений из большого списка мест хранений, например, в 100 и более объектов.
- SMORA00003354 Ошибка инициализации подчиненной БД.
- SMORA00003351 Ордер на доставку - неправильное поведение проверки 191, при создании нескольких ордеров.
- SMORA00003348 При переходе в раздел - Редактор налогов появляется ошибка.
- SMORA00003346 Расширение сообщений при приеме карточек по почте при изменении фиксированных атрибутов карточки товара.
- SMORA00003345 Калькуляция. Ошибка «Таблица не существует» после выполнения функции «Расчет плановой себестоимости».
- SMORA00003336 Отчеты. Проверка наличия рассчитанных налогов в кассовых документах.
- SMORA00003328 Расходная накладная. Ошибка отображения оснований для товародвижения.
- SMORA00003306 Ошибка при отборе накладной по фильтру, одно из условий которого «длинный» артикул.
- SMORA00003302 Текущий статус пакета почтового модуля отражен не по-русски.
- SMORA00003268 Тулбар иногда плохо восстанавливают своё расположение.
10.03.2010 16:49
Владимир
 
****************************************
********* Изменения СМ 1.027.3 *********
****************************************

17.02.10 (№ 971) SP № 3

Почтовый модуль. Исправлено: если прием массива объектов привел к удалению объектов базы, а затем этот массив объектов был отослан в ходе сквозной рассылки, то прием его в другой базе приводил к ошибке "Недопустимая операция над объектом 'OA'".
Sm.Post.DbLoader.dll

17.02.10 (№ 972) SP № 3

Формирование заказа ЕТС. При уменьшении кол-ва заказа на сумму дневных расходов, из периода учета дневных расходов исключена дата ближайшей готовности к продаже, т.к. расход за этот день учитывается ранее при определении остатка на дату ближайшей поставки.
StorePkgBody.sql

16.02.10 (№ 969) SP № 3

Формирование заказа ЕТС. 1) Добавлено округление кол-ва заказа до точности единицы измерения артикула. 2) Добавлен учет в алгоритме заказа минимального кол-ва заказа из контракта.
StorePkgBody.sql

09.02.10 (№ 967) SP № 3

Формирование заказа ЕТС. Исправлена ошибка "ORA-01476: делитель равен нулю", которая могла возникать при расчете коэффициента K1 в случае совпадения дат ближайшей и следующей поставки.
StorePkgBody.sql

05.02.10 (№ 962) SP № 3

SMORA00003337. Исправлено: при подключении по RDP на сервер СМ+, процесс SM.Main.exe занимает до 90% процессорного времени.
Sm.Forms.dll

05.02.10 (№ 965) SP № 3

SMORA00003323. Накладные. Исправлено: при удаленном поключении и срабатывании проверок в ходе смены статуса документа по кнопке "Обработать", окно проверок выводилось в виде ошибки, а не стандартного окна проверок.
Sm.Main.Server.dll

05.02.10 (№ 964) SP № 3

SMORA00003327. Цены. Исправлено: при удаленном подключении и разных настройках десятичных разделителей на ПК клиента и сервера, сохранение наценок при дробном значении шага цены приводило к ошибке "Задано недопустимое значение свойства Шаг цены".
Sm.Core.dll, Sm.Main.Server.dll

05.02.10 (№ 963) SP № 3

SMORA00003331. Исправлено: при удаленном подключении окно проверок не является модальным.
Sm.Main.exe

27.01.10 (№ 955) SP № 2

SMORA00003313. Ордер на доставку. Исправлен ряд ошибок.
pf_delivery_order.rep, Inspect.sql, SmDomDocsDO.dll, Docs3Pkg.sql, Doc3Proc.sql, Docs3PkgBody.sql, Inspect3PkgBody.sql

27.01.10 (№ 956) SP № 2

Маршрутный лист. Исправлен ряд ошибок.
SmDomDocsDO.dll, Doc3Proc.sql, Docs3PkgBody.sql

27.01.10 (№ 957) SP № 2

Административный модуль. Полный перерасчет остатков. Исправлено: неверно пересчитывалось значения "Резерв" и "Поставка", если складское требование запрашивало товар у подчиненного места хранения.
StorePkgBody.sql

27.01.10 (№ 958) SP № 2

SMORA00003300. Закрытие периода в производстве. Исправлено: если в ходе обрезки базы был удален не полностью расходованный или последний приход в пр-во, а затем был создан приход в пр-во с тем же номером, следующее закрытие периода в пр-ве выдаст ошибку нарушения FFCPRODAVAILINCOME_PK_.
PCloseBody.sql, PClose.sql

27.01.10 (№ 960) SP № 2

Почтовый модуль. Фильтр EDI. Реализован прием отклика от контрагента.
DocLabels.sql, SMPost.sql, Sm.Objects.dll, Sm.Post.DbLoader.dll, Sm.Post.Filters.dll, Sm.Post.Filters.Edi.dll

27.01.10 (№ 959) SP № 2

SMORA00003329. Накладные. Исправлено: функция "Проставить основания" с опцией "Проставлять цены из оснований" в расх. накл. с режимом округления "Полная цена" завершается ошибкой ORA-20707, если подобранная приход. накл. имеет режим округления "Цена без налогов".
SmCOMKernel.dll

18.01.10 (№ 950) SP № 1

SMORA00003310. Ордер на доставку. Исправлена ошибка заполнения комбо-бокса касс в диалоге добавления чека, мастере ввода товара и мастере создания нового документа.
SmDomDocsDO.dll

18.01.10 (№ 949) SP № 1

SMORA00003304. Почтовый модуль. Исправлено: если в администраторе создать первый почтовый ящик и если, не закрывая администратор, перейти на страницу редактирования обслуживаемых МХ, возникает ошибка "An item with the same key has already been added".
Sm.Post.Admin.exe

18.01.10 (№ 953) SP № 1

Сервер приложений. Исправлено: при подключении администратором сервера приложений к серверу приложений, установленному на другом компьютере, не работает функция удаления сессий пользователей сервера приложений.
Sm.AppServer.Admin.exe

18.01.10 (№ 952) SP № 1

SMORA00003295. Карточки. Исправлено: неверно отображалось правило проверки цен для артикула, который наследует это правило из своей группы классификатора.
PricePkg.sql, PriceTrg.sql, PricePkgBody.sql

18.01.10 (№ 954) SP № 1

Сервер приложений. Расширены сообщения при возникновении ошибок подключения к удаленному компьютеру.
Sm.Core.dll, Sm.Main.exe, Sm.Post.Admin.exe, Sm.AppServer.Admin.exe

18.01.10 (№ 951) SP № 1

SMORA00003315. Ордер на доставку. Реализован вывод диалога добавления новой строки спецификации при нажатии на кнопку "Добавить".
SmDomDocsDO.dll

13.01.10 (№ 944) SP № 1

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

13.01.10 (№ 940) SP № 1

Почтовый модуль. Исправлено: если в очереди на отсылку стоят запросы на синхронизацию объектов в разные почтовые ящики, то отправка во второй и последующие ящики завершается ошибкой: ORA-20012 Процесс синхронизации ProcessID=204 не зарегистрирован для БД RemoteDB=4.
Sm.Interfaces.dll, Sm.Post.DbLoader.dll, Sm.Post.Server.exe

13.01.10 (№ 941) SP № 1

Почтовый модуль. Исправлено: в запросах, где номер процесса учитывался как число, теперь номер процесса будет браться в одинарные кавычки, т.к. это строка.
Sm.Post.Controller.dll, Sm.Post.DbLoader.dll

13.01.10 (№ 943) SP № 1

SMORA00003303. Классификатор товаров. Исправлено падение программы при переходе на закладку "Среднесут. реал-ция".
SmDomService.dll

13.01.10 (№ 945) SP № 1

SMORA00003301. Выход из производства. Исправлено падение программы при заполнении спецификации остатками продукции в производстве.
SmCOMKernel.dll, SmDomDocs.dll, SmDomDocsAC.dll, SmDomDocsAD.dll, SmDomDocsBI.dll, SmDomDocsCC.dll, SmDomDocsCO.dll, SmDomDocsCS.dll, SmDomDocsDO.dll, SmDomDocsIL.dll, SmDomDocsMA.dll, SmDomDocsME.dll, SmDomDocsOR.dll, SmDomDocsPA.dll, SmDomDocsPR.dll, SmDomDocsRL.dll, SmDomDocsRO.dll, SmDomDocsSO.dll, SmDomDocsSR.dll

13.01.10 (№ 946) SP № 1

SMORA00003299. Накладные. Исправлено падение программы при выполнении функции "Наценить и принять" или "Отослать на корректировку".
SmLibraryBase.dll, SmDomDocsSO.dll, SmDomService.dll, SmToolsCore.dll, SmRepAdmin.dll

13.01.10 (№ 947) SP № 1

Почтовый модуль. Исправлено: закрытие сессий администратора выполнялось только по таймауту. Теперь добавлено принудительное закрытие сессий в момент закрытия диалогов настройки и правил рассылки.
Sm.Post.Admin.dll

13.01.10 (№ 948) SP № 1

Сервер приложений. Исправлено: сервер приложений, работающий в качестве сервера лицензий, не отслеживает отключение аппаратного ключа (не показывает в Администраторе).
Sm.Objects.dll, Sm.AppServer.exe

13.01.10 (№ 942) SP № 1

Почтовый модуль. Исправлено: если при включенном фильтре по типу процесса на странице "Синхронизация" создать новый процесс, то после завершения работы мастера создания нового процесса возникает ошибка: ORA-00918: столбец определен неоднозначно.
Sm.Post.Controller.dll

25.12.09 (№ 933) SP № 1

Заказ поставщику. Формирование заказа на базе контракта. Исправлено: при создании процесса из раздела "Реестр процессов" созданный процесс не мог открыться из-за ошибки "Процесс не найден".
SmDomDocsOR.dll

25.12.09 (№ 936) SP № 1

Маршрутный лист. Исправлен ряд ошибок.
SmDomDocsDO.dll, Docs3Pkg.sql, Doc3Proc.sql, Docs3PkgBody.sql, ClientModules.sql, SmPostTableLoad.sql

25.12.09 (№ 935) SP № 1

Ордер на доставку. Реализовано редактирование цен и сумм в документе. Создана функция "Проставить цены из основания доставки". Создана проверка 191 "Несоответствие цен в ордере на доставку и в документе основании (чеке или накладной)".
Documents.sql, Inspect.sql, Docs3Pkg.sql, Inspect3Pkg.sql, Doc3Proc.sql, Docs3PkgBody.sql, Inspect3PkgBody.sql, DocsPkgBody.sql, InspectLoad.sql, ClientModules.sql, SmDomDocsDO.dll

25.12.09 (№ 934) SP № 1

Накладные. Исправлено: начиная с версии 1.027.1 на некоторых базах наблюдалось замедление простановки цен последнего прихода.
DocsPkgBody.sql
19.04.2010 18:18
Владимир
 
****************************************
********* Изменения СМ 1.027.4 *********
****************************************

19.04.10 (№ 983) SP № 1

Исправлено: если расчет себестоимостных остатков вызывался не для всех данных, например, для одного магазина, то фильтр не устанавливался при отборе бухгалтерских справок, т.о. в результат всегда попадали все бухгалтерские справки указанного периода.
FRemainsPkgBody.sql

19.04.10 (№ 982) SP № 1

Бизнес-анализ. Исправлено для задач с остатками: если запустить задачу с установленным фильтром по артикулам, а затем удалить фильтр по артикулам и снова запустить задачу, то фильтр по артикулам перед расчетом остатков не будет сброшен.
RepToolsPkg.sql, RepToolsPkgBody.sql, AnalyticsPkgBody.sql

19.04.10 (№ 981) SP № 1

SMORA00003363. Накладные. Исправлено: в режиме "Отгрузка" или "Отгрузка со склада" при повторном сканировании товара обнуляется количество в расходной накладной.
SmDomDocs.dll

19.04.10 (№ 980) SP № 1

Сличительные ведомости. Исправлено: если в док-те с видом цены "цены поставки" имеются строки с ненулевым кол-вом, для которых значение поля SpecItem велико, то вызов функции "Проставить цены" приводит к ошибке: "Ошибка при присваивании значения свойству 'Пункт'".
SmDomDocsRL.dll

19.04.10 (№ 979) SP № 1

Административный модуль. Исправлено: если у пользователя есть право на просмотр док-тов по месту хранения (МХ), то ему разрешено и редактировать товародвиженческие документы этого МХ, хотя в администраторе установлен запрет на редактирование док-тов этого МХ.
OfficePkgBody.sql

19.04.10 (№ 978) SP № 1

SMORA00003369. Наценивание. Исправлена ошибка "ORA-06502: ошибка числа или значения", которая могла возникать при генерации актов переоценки в случае большого количества сгенерированных актов.
SmDomDocsCO.dll, SmDomDocsAC.dll, SmDomDocsPR.dll, SmDomDocsSR.dll, SmDomDocs.dll, RevalACPkg.sql, ProdProc.sql, DocProcExt.sql, DocsPkgBody.sql, RevalACPkgBody.sql

19.04.10 (№ 977) SP № 1

Расчет товародвижения. Исправлено: если имеется несколько магазинов, в каждом из которых были сначала расходы, а потом приходы, привязка к будущему приходу осуществляется только для одного магазина при наличии опции "Считать нулевую неопр. с/с по будущим приходам".
SmRepAdmin.dll


Опции темы


Часовой пояс GMT +3, время: 19:33.

 

Форум сделан на основе vBulletin®
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.