В текущей версии при списании немаркированной продукции по кассовым документам и при отгрузке по всем операциям, кроме «Списание брака» (порча), при подборе справок РФУ2 учитываются сроки годности продукции. Срок годности определяется по дате розлива продукции, которая указывается производителем в справке РФУ1, и по сроку годности из карточки артикула, связанного с кодом алкогольной продукции. Если в карточке товара срок годности не указан, срок годности продукции считается бесконечным. При подборе партии для списания подбираются поставки с самой ранней и еще не истекшей датой годности немаркированной продукции. Перед подбором справок РФУ2 для строк ТТН в ЕГАИС запрашиваются справки РФУ1 для получения информации о датах розлива немаркированной продукции. Справки запрашиваются только для партий немаркированной продукции, у которых есть остатки на первом регистре. Справки РФУ1 запрашиваются один раз и сохраняются в базе данных.

Запрос данных из ЕГАИС в ходе операции подбора кодов алкогольной продукции может заметно замедлить выполнение функции. Чтобы этого избежать, можно заранее выполнить функцию «Запрос содержания справок «РФУ1» из ЕГАИС» в разделе «ТТН ЕГАИС на приход» или аналогичную функцию в разделе остатков ЕГАИС (см. ниже).

Для контроля сроков годности в таблицу остатков регистра склада в разделе «Остатки ЕГАИС» добавлено поле «Дата розлива». Также в таблицу добавлено поле «ТТН», по которой пришла партия:

В раздел «Остатки ЕГАИС» добавлена функция «Запрос содержания справок «РФУ1» из ЕГАИС». Функция действует для выбранных строк таблицы остатков:

Функция позволяет заранее запросить справки РФУ1 по тем позициям, по которым они будут использоваться:

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

Для ТТН ЕГАИС на отгрузку создана функция проверки 245 «Контроль срока годности пивной продукции». По умолчанию функция имеет режим работы «Предупреждение». Проверка срабатывает для немаркированной продукции из спецификации ТТН ( кроме операции «порча»), если дата окончания срока годности продукции меньше даты отгрузки продукции. Функция проверки выполняется при отсылке ТТН в ЕГАИС.

Прием и списание / отгрузка разливного пива в штучной упаковке.

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

С точки зрения ЕГАИС, одна и та же продукция, как фасованная (в штучной упаковке), так и нефасованная (то есть учитываемая в декалитрах) - это разная продукция с разными кодами алкогольной продукции. Если производитель предполагает декларировать выпуск продукции в ЕГАИС и в фасованном и в нефасованном виде, то есть в штуках или декалитрах, он должен зарегистрировать такую продукцию раздельно и получить для нее разные коды алкогольной продукции. Такие правила регистрации продукции в ЕГАИС не делают товар разным, и штриховой код EAN и у той, и у другой продукции, как правило, одинаковый. С точки зрения торгового предприятия это один и тот же артикул. Кроме того, по правилам торговли регистрация поступления товара должна производиться в тех единицах измерения, в которых будет производиться ее отпуск. Если товар продается в розлив, его единица измерения в торговой организации будет «литр». При приеме алкогольной продукции, соответствующей этому артикулу, и для фасованной и для нефасованной продукции прием артикула должен выполняться в его единице измерения, то есть в литрах.

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

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

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

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

Примечание: при ручном добавлении кода алкогольной продукции в таблицу кодов разрешается вводить только код алкогольной продукции. Прочие атрибуты необходимо получать из ЕГАИС запросом.

При приеме ТТН на приход после сопоставления позиций ТТН с позициями накладной происходит автоматическое добавление всех новых кодов алкогольной продукции в карточку товара. В этом случае информация о типе упаковки вместе с другими атрибутами кода алкогольной продукции берется из ТТН ЕГАИС.

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

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

Например, прием 16 кэг емкостью 50 л. по накладной на 800 л.

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

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

То есть для фасованной продукции списание кэги происходит по факту первой продажи.

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

Если разливного остатка достаточно для списания пива, то количество списываемой продукции в ТТН будет 0. При отсылке ТТН строки с нулевым количеством не будут добавлены в файл почтового пакета и, при наличии других строк, документ будет корректно отослан и обработан в ЕАГИС.

Для контроля текущих остатков по вскрытым кэгам в раздел «Остатки ЕГАИС» добавлена закладка «Разливное пиво»:

Фактические остатки вскрытых кэг по разным причинам могут разойтись с учетными данными. Это может привести к тому, что при замене кэги на новую в остатках будет числиться прежняя, и в ЕГАИС не будет списана новая кэга, пока не будет исчерпан остаток прежней. Это не представляет проблемы до тех пор, пока срок годности очередной списываемой кэги из-за смещения очереди кэг не окажется меньше необходимого. Эту проблему можно решать периодической инвентаризацией и списанием учетных излишков кэг. Для оперативной коррекции розливных остатков и сброса остатка текущей кэги в раздел «Остатки ЕГАИС» добавлена новая функция «Коррекция разливного остатка». Для использования функции необходимо иметь функциональное право «Коррекция разливного остатка»:

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

При установке остатка в значение 0 строка с соответствующим кодом алкогольной продукции из таблицы исчезает. При очередной продаже продукции в ЕГАИС будет списана очередная кэга и начнется новый отсчет разливного остатка вскрытой кэги.

Определение ФСРАР ИД при отсылке ТТН ЕГАИС контрагенту, не имеющему КПП.

При отсылке ТТН на расход в ЕГАИС в ТТН необходимо корректно заполнить атрибуты контрагентов ЕГАИС - участников обмена. Чтобы получить текущие атрибуты контрагента, делается запрос в ЕГАИС. По протоколу ЕГАИС запросить можно только информацию для всего контрагента целиком по его ИНН. В ответ ЕГАИС возвращает перечень атрибутов контрагента с привязкой к ФСРАР ИД контрагента. Среди перечня атрибутов для каждого ФСРАР ИД обычно имеется КПП контрагента. Это позволяет определить ФСРАР ИД и связанные с ним атрибуты контрагента ЕГАИС по КПП контрагента Торговой Системы.

Выяснилось, что контрагенты – индивидуальные предприниматели не имеют КПП и в то же время могут иметь множество магазинов, каждый со своим ФСРАР ИД. В этом случае в предыдущих версиях ФСРАР ИД контрагента ЕГАИС определялся некорректно, и ТТН отправлялось не тому адресату.

Для однозначного определения ФСРАР ИД и связанных с ним атрибутов контрагента ЕГАИС в раздел «Контрагенты» на закладку «Склады» в таблицу складов контрагента добавлено поле «Ид. ФСРАР»:

В заголовок расходной накладной на закладку «транспортный раздел» добавлено новое поле «Ид. ФСРАР». При выборе склада контрагента в накладной в документ автоматически проставляется значение ФСРАР ИД из карточки контрагента:

В документе это поле можно отредактировать вручную.

Если в расходной накладной задан ФСРАР ИД, он будет использоваться для определения данных контрагента, полученных из ЕГАИС. После получения данных о контрагенте по ИНН его атрибуты будут искаться по совпадению ФСРАР ИД и КПП, если он есть. Если эти параметры не совпадут с данными ЕГАИС, контрагент подобран не будет и документ не отошлется.

Маркировка.

Повторный прием УПД после приема с ошибками.

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

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

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

Дополнительно в журнал истории документа «УПД на приход» добавлено поле «Сумма» документа.

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

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

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

Отсылка УКД при отгрузке товара в случае получения акта приемки с расхождением.

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

Если в ответ на УПД с операцией «Отгрузка получателю» приходил акт приемки с кодом ответа «2» (прием с расхождением) и в файле акта приемки (UDCONFIRM) имелась спецификация принятого товара, то создавался новый документ «УПД на отгрузку» с операцией «Акт приемки», статусом «Сформирован» и спецификацией из акта приемки.

Примечание. Документ с операцией «Акт приемки» предназначен для информирования о решении контрагента и, несмотря на то, что это документ имеет тип «УПД на отгрузку», не предназначен для пересылки контрагенту.

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

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

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

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

Примечание: если в расходной накладной имеются коды КИЗ для продукции с объемно-сортовым учетом, то при коррекции накладной по акту приемки они исчезнут, поскольку для такой продукции акт приемки содержит только указание на количество кодов КИЗ, но не сами коды. Это не мешает последующему правильному формированию почтового пакета для скорректированного файла УПД на отгрузку или УКД (см. ниже) при отсылке документа провайдеру.

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

Для принятия решения об отсылке УПД или УКД добавлена обработка тэга «ANSWERTYPE» при приеме файла акта приемки (тэг «ANSWERTYPE» в файле UDCONFIRM может принимать значение «УПД» или «УКД») и в раздел контрагентов на закладку «ЭДО» добавлена опция «ЭДО при отгрузке с расхождением»:

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

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

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

В обоих вариантах в документ «УПД на отгрузку» теперь проставляется номер исправления (+1 к максимальному номеру предыдущих исправлений по одной и той же расходной накладной), указывается номер предшествующего УПД и его дата. Для этого в заголовок УПД на отгрузку добавлена закладка «Исправления»:

Подсчет кодов КИЗ. Функция «Экспорт кодов КИЗ в файл».

В раздел «Подсчет кодов КИЗ ТСД» добавлена функция «Экспорт кодов КИЗ в файл». Функция доступна в открытом процессе. Функция выгружает данные в файл формата CSV . Диалог функции позволяет указать или выбрать имя файла для экспорта:

Коды КИЗ помещаются в файл с преобразованием по правилам ЦРПТ, как это делается перед помещением кодов в УПД на отгрузку. То есть КИЗ в выгруженном файле не содержат нечитаемых символов и коды применения, связанные с контрольными суммами и другими специфическими данными КИЗ. Например:

010460143993125621nNc3bUI8005122000

010460720309891021nNc3bUI8005122000

010460143993125621pz>,!A:

Меркурий.

Справочники ГИС «Меркурий». Справочник целей (назначения грузов).

В раздел «Справочники ГИС «Меркурий»» в дополнение к справочнику единиц измерения добавлена закладка со справочником целей (назначения грузов):

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

Остатки ГИС «Меркурий».

Создан новый раздел «Остатки ГИС «Меркурий»» для просмотра текущих остатков по номенклатуре в ГИС Меркурий.

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

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

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

В интерфейсе раздела показывается дата и время последнего получения остатка из ГИС Меркурий:

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

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

Гашение ВСД с составлением акта несоответствия.

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

В текущей версии реализован протокол приема продукции, если количество принятой продукции меньше количества в ВСД на величину большее, чем 5%.

В ГИС Меркурий предусмотрено два сценария приема с расхождением: когда часть продукции возвращается и когда возврата разницы количества принятой и отгруженной продукции не происходит (если расхождение обусловлено потерями при транспортировке или ошибками). В текущей версии реализован сценарий приема с потерями при транспортировке. В этом случае в ГИС Меркурий отсылается только акт несоответствия.

При выполнении процедуры гашения делается проверка соответствия количества принятой продукции и количества продукции в ВСД. Если разница превышает 5% от количества в ВСД в меньшую сторону, показывается следующий диалог:

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

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

После указания причины несоответствия команда гашения и акт отсылаются в ГИС Меркурий и ВСД гасится:

Если количество в приходной накладной превышает количество в ВСД более чем на 5%, то при гашении будет показано следующее сообщение:

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

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

Автоматическая генерация заданий для Супермаг Мобайл 3.

В прошлых версиях был создан раздел «Управление заданиями Супермаг Мобайл 3». Раздел позволяет администрировать задания для СМ Мобайл 3, в том числе, создавать задания и принимать результаты выполнения этих заданий.

В текущей версии в раздел добавлена возможность создавать правила для автоматической генерации заданий СМ Мобайл 3:

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

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

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

Раздел позволяет создавать задачи трех типов:

Сборка мусора предназначена для удаления с сервера Мобайл 3 заданий, у которых дата создания отстоит от текущей более указанного количества дней:

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

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

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

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

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

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

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

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

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

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

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

Когда тип задания требует наличие в задании спецификации из артикулов с количеством, предлагается указать тип документа-основания:

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

Документ «Калькуляция». Калькулятор цен и сумм спецификации документа.

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

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

В предыдущей версии цена 770,33 после обратного прересчета была бы установлена в 770,3276.

Раздел « Остатки ». Поля «Единица измерения» и «Среднесуточная реализация».

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

При отображении в таблице значение среднесуточной реализации берется из карточки складского учета.

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

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

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

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

Кассовый модуль. Протокол УКМ4 XML. Прием из кассы информации о смене.

В текущей версии расширен перечень принимаемой информации о смене ККТ, которую выгружает касса по протоколу УКМ4 XML . Из файла с данными закрытой смены (вида shift_[4]_[2]_[1679]_[1]. xml ) теперь принимается информация из следующих тэгов заголовка смены:

<kkm_shift_number> - номер смены ККТ. В УКМ4 номер смены (shiftNum) формируется с привязкой к кассе и не связан с номером смены, который формируется фискальным регистратором (ККТ). Это сделано для того, чтобы не менять номер кассы при замене фискального регистратора.

< kkm _ serial _ number > - серийный номер ККТ (производителя)

< kkm _ registration _ number > - регистрационный номер ККТ (в налоговой инспекции).

Эта информация принимается только из закрытых смен, в оперативных чеках ее нет.

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

Для просмотра информации о смене в разделе кассовых чеков в перечень полей, доступных для выбора в диалоге кнопки «Поля…», добавлены флаги «№ Z отчета ККТ », «Регистрационный номер ККТ» и «Серийный номер ККТ»:

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

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

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

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