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

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

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

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

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

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

Номер Z отчета гарантировано становится известным только после закрытия смены. Наличие номера Z отчета в оперативном чеке зависит от программы ККМ. Если в качестве программы ККМ используется УКМ 2 или УКМ 4, то номер Z отчета для оперативного чека известен. Дата Z отчета никогда достоверно не бывает известной до момента закрытия Z отчета.

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

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

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

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

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

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

Создан отчет «Реестр счетов-фактур кассовых документов». Отчет позволяет получить суммы НДС, полные суммы и суммы без НДС, уплаченные покупателем – плательщиком НДС при продаже товаров через кассу. Отчет позволяет получить итоги сумм отдельно по продажам и отдельно по возвратам.

Функции проверки контрактов на закупку.

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

Планирование цен.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для строк, в которых показывается история выполнения плана цен, колонка основание не заполняется.

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

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

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

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

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

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

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

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

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

Алгоритм расчета из карточки складского учета был следующий:

ССР = среднесуточная продажа - среднесуточный возврат.

Среднесуточная продажа = кол-во продаж / (максимальная дата продажи - минимальная дата продажи + 1).

Среднесуточный возврат = возвратов / (максимальная дата возврата - минимальная дата возврата + 1).

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

ССР = ([кол-во продаж] - [кол-во возвратов]) / ([максимальная дата реализации] - [минимальная дата реализации]+1).

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

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

Условие все дни:

Для условия - за все время,

ССР = (все продажи - все возвраты)/(дата последней продажи - дата первой продажи + 1)

Для случая ограничения дат,

ССР = (продажи в диапазоне - возвраты в диапазоне)/кол-во дней диапазона

Условие "только дни продаж"

За все время,

ССР = (все продажи - все возвраты)/кол-во дней, в которые были продажи

За диапазон времени,

ССР = (продажи - возвраты)/кол-во дней продаж в диапазоне

Экспорт данных.

В тип экспорта "Операции" добавлены два новых поля: "ID операции" и "ID пользовательской операции". В новых полях выводятся, соответственно, коды системной операции и код пользовательского расширения операции.

Атрибут «Плательщик НДС» для контрагентов.

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

Сохранение и восстановление фильтров в разделах.

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

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

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

Терминал сбора данных Falcon 4220. Драйвер обмена ScanPlus . Net .

Создан драйвер ScanPlus . Net для обмена данными с портативным терминалом сбора данных типа Falcon 4220 с программой « ScanPlus . Net ». Драйвер ScanPlus . Net поддерживает режимы обмена данных для процессов инвентаризации количества товара, контроля ценников и контроля приема и отпуска товара на основании документов: Заказ, Приходная накладная, Накладная на перемещение и Расходная накладная.

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

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

Falcon 4220 представляет собой мобильное устройство с операционной системой Windows CE . Net

Обмен данными с ним производится через инфракрасный порт или USB порт с использованием программы ActiveSync .

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

Непосредственно перед началом обмена необходимо установить физическую связь с мобильным устройством – подсоединить его к USB порту или удостовериться в наличии связи по инфракрасному порту и убедиться, что индикатор Microsoft ActiveSinc опознал соединение. Фактическая связь между стационарным компьютером и мобильным устройством устанавливается в течение некоторого времени после опознания мобильного устройства, поэтому необходимо подождать несколько секунд, прежде чем пытаться осуществить обмен данными. Если соединение установлено (индикатор зеленый), а попытка обмена не удалась и получено сообщение «Терминал не обнаружен. Проверьте наличие ActiveSync соединения» или «Ошибка записи в файл на терминал», необходимо обмен повторить, подождав некоторое время.

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

Обмен данными с программой терминала сбора данных ScanPlus . Net построен на принципе обмена файлами через каталог обмена мобильного устройства. Для передачи данных в мобильное устройство используется файл с именем scanin.dat , для приема данных файл с именем scanout.dat. При очередном обмене данными предыдущий файл замещается новым. В связи с этим необходимо следить за тем, чтобы новый обмен данными не происходил до полного завершения работы с предыдущими данными.

Загрузка в весы срока годности и срока реализации.

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

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

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

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

Поле «Годность» имеет три градации :

– красный - «не годен» – дата истечения годности строго меньше текущей даты,

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

– зеленый - «годен» - дата истечения годности больше или равна текущей дате и больше или равна дате конца реализации.

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

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

Создана функция проставления (обновления) даты «Годен до». Функция вызывается кнопкой «Срок годности». Функция отыскивает последние приходные накладные с операцией «Приход» в текущем месте хранения и в старшем для него месте хранения с датами годности для товаров из списка загрузки.

Внесены изменения в драйвер весов Digi . Значение поля «Годен до» помещается в поле специальных сообщений файла товара « F 25»,.

Для других типов весов загрузка срока годности не реализована.

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

Протокол загрузки касс УКМ 2 для Республики Украина.

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

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

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

Управление флагом находится в административном модуле в разделе «База данных», страница «Конфигурация», папка «Кассы», группа параметров «Загрузка».

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

Понятие «налоговая группа» в торговой системе и в программе УКМ 2 не совпадают в полной мере. Для установления соответствия между налоговыми группами УКМ и налоговыми группами торговой системы для налоговой группы добавлен атрибут «тип группы». Тип группы может принимать одно из четырех значений, определенных законодательством Украины: «А», «Б», «В» или «Г». По умолчанию, налоговой группе торговой системы присваивается значение типа группы «А».

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

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

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

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

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

Пересоздание индексов.

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

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

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

Местоположение файла трассировки supermag_trace.log.

Файл трассировки ошибок обращения к базе данных в предыдущих версиях размещался по фиксированному пути c :\ supermag _ trace . log .

Начиная с текущей версии файл размещается во временном каталоге текущего пользователя, например: “C:\Documents and Settings\ UserName \Local Settings\Temp”.

Печатная форма счета в базовой валюте.

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

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

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

Дополнительно, при печати счета в режиме «детально по скидкам», печатается фактически предоставленная скидка в процентах.

Отчет «Контракты по товару».

Отчет находится в группе отчетов «Менеджерские».

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

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

Отчет имеет следующие опции:

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

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

- "Только артикулы с любыми контрактами". В отчет попадают артикулы, для которых существуют контракты в статусе "Принят".

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

Отчет «Движение в производстве в закупочных ценах».

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

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

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

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

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