Petroglif

Интерфейс с сервисом IP-телефонии

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

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

Настройка работа с телефонным сервисом

Справочник телефонных сервисов

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

Соответствующий справочник доступен по меню Справочники/Оборудование/Телефонные сервисы.Диалог редактирования записи сервиса показан на рис. link.

Запись настройки телефонного сервисаВот список и назначение полей этого диалога.

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

▼Тип сервиса

Зарезервированный на будущее комбо-бокс для выбора типа сервера (сейчас работа возможна только с сервером Asterisk).
Адрес сервера
ip-адрес и (опционально) порт сервера.
Авторизация
Имя авторизации на телефонном сервере и пароль.
Символ локального канала (Up)
В этом поле указывается префикс канала, для которого включается реакция на подъем телефонной трубки. Для сервера Asterisk обычно этот символ задается как SIP/999 где 999 - локальный номер телефона сотрудника, к чьему рабочему месту относится компьютер, на котором настраивается запись. Важно: этот символ хранится не в базе данных, а в локальном реестре на компьютере. Таким образом, одна запись на разных компьютерах может (и, вероятно, должна) иметь разные символы локального канала.

Если данный компьютер должен реагировать на подъем трубки для нескольких префиксов канала, то в этом поле можно прописать их все, разделяя запятой или пробелом. Специальный символ - является локальным представлением объекта A, а в разделе X этому объекту соответствует представление Ax. Теперь нам необходимо выяснить, что происходит, когда из раздела X в раздел Y передается объект (скажем, B), для которого и в том и в другом разделах существуют представления (соответственно Bx и By). Раздел-получатель, обнаружив, что принимаемый им объект Bx имеет собственное представление By, может либо изменить By так, чтобы он соответствовал Bx, либо отклонить изменение. Алгоритм принятия решения об этом достаточно сложен из-за того, что он опирается как на общую технику (справедливую для всех типов объектов), так и на особенности конкретных типов объектов. Общая техника предполагает три варианта:

  • Объект в разделе-приемнике не изменяется
  • Объект в разделе-приемнике безусловно изменяется
  • Объект в разделе-приемнике изменяется, если он старше объекта, полученного от раздела-отправителя.
  • Последний вариант предполагает, что система сравнивает время последней модификации объекта в разделе-приемнике со временем последней модификации объекта в разделе-отправителе (это время передается вместе с объектом). Если полученный объект имеет более позднее время изменения, то система модифицирует представление объекта.

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

    Акцепт объекта

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

    Разрешение ссылок

    Технология разрешения ссылок необходима для того, чтобы при передаче объекта из одного раздела в другой сохранялась его целостность. Большинство типов объектов не существуют сами по себе, а зависят от других объектов. Так, товар, принадлежит товарной группе, относится к какой-либо (возможно пустой) торговой марке, имеет единицы измерения и т.д. В свою очередь, товарная группа, торговая марка и единица измерения сами являются объектами, которые необходимо синхронизировать между разделами базы данных. Суть техники разрешения ссылок заключается в том, что при передаче объекта, вместе с ним передаются все объекты, от которых он зависит. По принципу матрешки те объекты в свою очередь “тянут” за собой объекты, от которых зависят сами. Таким образом, при передаче, допустим, одного товара из раздела в раздел будет передан объем данных значительно превышающий тот, что занимает один товар. Следующим шагом является преобразование ссылок из раздела-отправителя на значения, соответствующие им в разделе-получателе. Весь процесс передачи и разрешения ссылок, естественно, полностью автоматический.

    Приоритет приема объекта

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

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

    Для релиза 5.6.8 и выше применяется следующая схема назначения приоритетов:

  • Динамические объекты - 100
  • Типы тегов объектов - 120
  • Документы, относящиеся к типу операции Приход товара - 200
  • Прочие документы, которые только увеличивают товарные остатки - 220
  • Документы модификации товаров - 240
  • Документы, который только расходуют товар - 280
  • Все остальные документы - 300
  • Зависимые объекты (которые не должны акцептироваться независимо от основного объекта) - 2000
  • Остальные объекты - 1000
  • Отложенная фиксация транзакции приема данных

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

    Как Papyrus обрабатывает объединенные объекты?

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

    Для иллюстрации того, что происходит с объединяемыми объектами, приведем схематическое изображение двух объектов A и B, представленных в двух разных разделах базы данных. После объединения объектов в разделе Y объект A по-прежнему существует и в X и в Y, а объект представление объекта B осталось только в разделе X.Передача данных из Y в X не претерпела никаких изменений (за исключением того, что пользователи в X с удивлением обнаружили отсутствие каких-либо операций или событий по объекту B, приходящих к ним из раздела Y).

    Передача же из X в Y несколько усложнилась. Теперь, если в Y приходит объект B (или что-либо с ним связанное), система в разделе Y увидев это, не должна пытаться создать локальное представление, но должна понять, что в действительности, пришел объект A (ибо для Y после объединения A с B это так). Для решения этой задачи, система, обнаружив необходимость акцепта отсутствующего объекта, ищет в системном журнале информацию о том, не был ли этот объект объединен с каким-либо иным. Если да, то идентификатор B подменяется локальным идентификатором Ay.

    Принцип равнозначности разделов

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

    Принцип соблюдения прав доступа

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

    Какие объекты базы данных должны синхронизироваться?

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

    Тип объекта Электронные весы

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

    Тип объекта Вид операции

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

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

    Некоторые технические особенности

    Администраторам системы и специалистам, сопровождающим программный продукт, следует знать следующие особенности обмена данными в системе Papyrus .
  • Формат файлов передачи данных является бинарным и не документированным. В связи с тем, что иногда (не часто) формат меняется, важно помнить, что версию системы в этом случае следует менять во всех разделах базы данных. Информация об этом обязательно публикуется в файле истории версий DOC/VERSION.TXT. В систему встроена защита от обмена данными между несовместимыми по формату передачи версиями.
  • В системе существует опция сжатия файлов передачи данных с тем, чтобы сократить объем передаваемой информации по “узким” каналам связи (Админ→ Прочие конфигурации→ Конфигурация обмена данными→ Упаковывать файлы перед отправкой).
  • Система полагается на правильность настройки записей разделов базы данных. Это значит, что вы должны очень аккуратно подойти к вопросу формирования этих записей, а так же ограничить права доступа обычных пользователям на изменения этих записей.
  • Настройка разделенных баз данных

    Как правило, процесс настройки разделенной базы данных состоит в репликации некоторой существующей базы - то есть в создании базы данных нового раздела (реплики), связанной с существующей базой данных. Под словом “связанной” мы подразумеваем то, что все объекты данных, находящиеся в существующей базе и требующие синхронизации будут синхронизированы с репликой.

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

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

    Если нет, то следует создать новую запись для текущего раздела базы данных (диалог редактирования записи раздела базы данных описан ниже). Как система определяет, к какому из разделов в справочнике относится текущая база данных? Выберите пункт меню Админ→ Конфигурация. В появившемся диалоге нажмите кнопку [Конфигурация]. Комбо-бокс “Раздел БД” указывает раздел, который является текущим.

    Создание записи о создаваемой реплике базы данных (раздел базы данных: реплицируемая база данных)

    Меню Справочники→ Админ→ Разделы базы данных. Внесите новую запись для создаваемой реплики. Обязательно обратите внимание на идентификатор новой записи: он должен быть уникальным среди всех разделов и его значение не должно превышать 255. На текущий момент управление идентификаторами разделов является полностью ручной операцией. Еще раз обратим внимание на уникальность идентификатора: так как вы имеете дело с территориально разделенными базами данных, то проследите, чтобы ни в одной из баз данных среди группы, участвующей в обмене не существовало вновь создаваемого идентификатора раздела - система не сможет за вас сделать эту работу, так как не имеет постоянной гарантированной связи с остальными разделами.

    Автосинхронизация (раздел базы данных: реплицируемая база данных)
    Откройте новый сеанс работы с текущей базой данных и войдите в него с именем system при этом введите пароль пользователя master. Выберите меню Разное→ Автосинхронизация.

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

    1. Создание точной копии существующей базы данных. Для этого просто скопируйте весь каталог реплицируемой базы в другой каталог. Тот другой каталог и станет репликой текущей базы. Этот метод следует применять в случае, если вы сделали полную автосинхронизацию (с документами).
    2. Создание базы данных по образцу. Для этого запустите сеанс Papyrus , выберите пункт меню Админ→ Создание базы данных. Выберите вариант создания “По образцу”. Подробно создание базы данных описано в разделе, посвященном администрированию.
    Этот вариант создания реплики базы данных применяется в том случае, если автосинхронизация реплицируемой базы осуществлялась “без документов”.
    Настройка реплики (раздел базы данных: реплика)

    Единственное принципиальное действие, которое вам необходимо сделать во вновь созданной реплике - это установка текущего раздела базы данных. Для этого зайдите в базу данных новой реплики, выберите пункт меню Админ→ Конфигурация, в появившемся диалоге нажмите кнопку [Конфигурация] и в поле “Раздел БД” выберите запись, соответствующую новому разделу. После переноса этой базы данных на сервер, на котором она будет использоваться, следует правильно настроить пути Админ→ Конфигурация→ Пути. При этом помните, что группы и (или) пользователи могут име?ь собственные настройки путей. Определитесь с механизмом переноса данных из одного раздела в другой (электронная почта, магнитные носители и т.д.) и осуществите необходимые настройки.

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

    Раздел базы данных

    Вид окна диалога редактирования раздела базы данных показан на рис. link. Далее приводится описание его управляющих элементов.

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

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

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

  • Если адрес раздела, в который отправляются данные пустой, то файлы передачи данных никуда не копируются и остаются в каталоге OUT.
  • Если адрес раздела, в который отправляются данные, содержит символ @, то система воспринимает эту строку как адрес электронной почты и пытается отправить файлы передачи на этот адрес, используя учетную почтовую запись в конфигурации глобального обмена Админ→ Прочие конфигурации→ Конфигурация глобального обмена.
  • Если адрес раздела не пустой и не содержит символа @, то система трактует его как каталог файловой системы (проверяя его предварительно на существование) и копирует файлы передачи данных в этот каталог. При получении данных, система ориентируется и на адрес текущего раздела и на адреса других разделов базы данных. Здесь правила следующие:
  • Если адрес текущего раздела не пустой, то система трактует его как каталог входящих файлов и переносит файлы из этого каталога в каталог IN для дальнейшей обработки файлов.
  • Если адрес текущего раздела пустой и какой-либо из адресов других разделов содержит символ @, то система обращается к серверу электронной почты за почтовыми сообщениями, имеющими тему (subj) $PpyDbTransmission$. Все письма с этой темой забираются с сервера, распаковываются и обрабатываются в каталоге IN.
  • Следствием вышесказанного является то, что в собственном разделе, если файлы данных не приходят к нему из другого каталога, поле адрес должно быть пустым.

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

    Система идентифицирует таблицу статей складов в соответствии с установкой в меню Админ→ Конфигурация→ [Конфигурация], поле “Таблица позиций”.

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

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

    ✓Диспетчерский раздел

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

    ✓Обмен только по пластиковым картам

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

    ✓Принимает кассовые сессии вместе с документами списания

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

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

    ✓Принимает документы без товарных строк

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

    ✓Пассивный

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

    Синхронизация разделенных баз данных

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

    Передача данных в другие разделы

    Существуют следующие способы передачи данных из текущего раздела в другие:

    1. Передача измененных объектов
    2. Специализированная передача документов
    3. Передача из системного журнала
    4. Передача из таблиц просмотра объектов.
    5. Передача с использованием сервера задач
    Опишем каждый из этих методов подробно.

    Передача измененных объектов

    Перенос измененных объектов

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

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

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

    ✓Очищать источник

    Если этот флаг установлен и, в соответствии с настройками раздела-получателя, файлы передачи должны либо копироваться на дисковый каталог, либо передаваться по электронной почте, то после копирования сформированные файлы будут удалены из каталога OUT (системного каталога исходящих файлов).

    ✓Очищать приемник

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

    Список “Разделы БД”

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

    Список “Передавать объекты”

    Список типов объектов, которые необходимо обработать. Здесь можно выбрать любое количество типов объектов.

    Для выбора всех возможных типов объектов нажмите кнопку [Добавить] и в появившемся диалоге нажмите кнопку [>>]. В результате все записи из левого списка попадут в правый список типов объектов для передачи.

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

    ✓Передать информацию о синхронизации

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

    Специализированная передача документов

    Так как для многих организаций документы являются центральным объектом учета, в систему включена отдельная функция передачи документов за определенный период. Если не считать специальных и крайне редко используемых опций, эта функция является избыточной и перекрывается другими методами передачи объектов. По этому, в общем случае, использование специализированной передачи документов не рекомендуется. Доступ к этой функции осуществляется через пункт меню Админ→ Обмен данными→ Передать документы.

    Перенос документовДиалог параметров функции показан на рис. link. Он содержит следующие управляющие элементы.

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

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

    ✓Очищать источник

    Если этот флаг установлен и, в соответствии с настройками раздела-получателя, файлы передачи должны либо копироваться на дисковый каталог, либо передаваться по электронной почте, то после копирования сформированные файлы будут удалены из каталога OUT (системного каталога исходящих файлов).

    ✓Очищать приемник

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

    Список “Разделы базы данных”

    Список разделов, в которые следует передать объекты. Вы можете выбрать здесь любое количество разделов-приемников.

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

    Передача из таблиц просмотра объектов

    Многие таблицы просмотра объектов данных (документы, товары, персоналии и т.д.), а также некоторые списки просмотра объектов (группы товаров, товарные корзины и т.д.) предоставляют сервис передачи выборки объектов в другие разделы. В таблицах для этого служит комбинация клавиш <Ctrl-H> , в списках - кнопка [Передать]. При выборе такой команды на экране появляется диалог передачи объектов. Этот диалог аналогичен диалогу передачи измененных объектов за исключением того, что вместо указания даты и времени, начиная с которых следует передавать изменения, содержит переключатель “Протокол изменения объектов в разделе-адресате”. Остановимся на этом моменте.

    Протокол изменения объектов может иметь одно из трех значений:

    Не изменять
    Этот вариант предписывает системе принять в разделе-приемнике только новые объекты (то есть те, которых в том разделе нет). Никакие из уже синхронизированных объектов при этом не меняются.

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

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

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

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

    Прием данных из других разделов

    Прием данных из других разделов

    Для приема данных из других разделов выберите пункт меню Админ→ Обмен данными→ Принять почту. На экране появится диалог, изображенный на рис. link. Этот диалог содержит следующие управляющие элементы

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

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

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

    ✓Непосредственная фиксация транзакции

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

    ✓Очистить очередь после фиксации транзакций

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

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

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

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

    Просмотр очереди приема объектов

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

    Очередь синхронизации

    Принять данные (фиксировать транзакцию)
    <F8> Вызывает диалог приема данных из других разделов. Эта функция полностью аналогично обращению к пункту меню Админ→ Обмен данными→ Принять почту. Единственное (положительное) отличие заключается в том, что вы сможете сделать это наблюдая за очередью синхронизации.

    Очистить очередь
    <Ctrl-F8> Полностью очищает очередь синхронизации. Перед выполнением этой функции система запрашивает подтверждение.
    Фильтр
    <Ctrl-V> Просто обновляет содержимое таблицы.

    Разрешение проблем

    При приеме данных из других разделов возможно возникновение ряда проблем, которые можно разделить на следующие группы:
  • Дефицит учетных остатков на складе, по которому принимаются расходные документы
  • Нарушение синхронизации объектов
  • Разберем каждую группу проблем

    Дефицит учетных остатков

    Этот конфликт возникает в том случае, если при приеме расходного документа в базе-приемнике не хватает учетных остатков для проведения документа. Система выдает исчерпывающую диагностику этих проблем при приеме данных. Если рассматриваемый дефицит не является штатной ситуацией (такие ситуации будут описаны ниже), то наиболее правильным выходом из ситуации является сведение учетных остатков по дефицитным позициям с разделом отправителем. Для этого хорошо подходит анализ товарных операций по дефицитному товару и по складу, по которому не удается провести расход. Более грубым (и, соответственно, менее правильным) методом борьбы с таким дефицитом является автоматический форсированный приход недостающих позиций. Для этого в системе предусмотрена специализированная опция: в конфигурации обмена данными установите флаг ✓Приходовать итоговый дефицит. Одновременно в общих настройках (Админ→ Настройки→ Операции) должен быть установлен вид операции “Приход от поставщика”, который будет использован для приходования дефицитных позиций.

    Нарушение синхронизации объектов

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

    Наиболее “изученным” является случай неправильной синхронизации объектов. То есть, системная синхронизация зафиксировала связь объекта в одном разделе с объектом, совершенно не соответствующим этому, в другом разделе. Например, товар “Творог Крестьянский” в разделе A соответствует товару “Вермишель ажурная” в разделе B.Известным симптомом неправильной синхронизации может быть невозможность принять объект (например, документ или кассовую сессию) в раздел-получатель, несмотря на видимое отсутствие причин для этого.

    Сравнение синхронизации объектов

    Анализ синхронизации объектов

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

  • Из одного раздела в другой передается выборка объектов с установленным признаком ✓Передать информацию о синхронизации
  • В разделе-приемнике запускается функция “Анализ синхронизации объектов”. Если раздел-приемник обнаружит файлы с переданной информацией о синхронизации, то на экране будет показана таблица сравнения синхронизации.
  • Просмотр объекта
    <Enter> Показывает свой объект, соответствующий выбранной строке

    Удалить информацию о синхронизации объекта (по общему ид-ру)
    <Delete> Удаляет информацию о синхронизации, соответствующую выбранной строке. Это действие может потребоваться для устранения неверной синхронизации (обычно при коде ошибки 2 и низкой величине сравнения наименований своего и чужого объектов).
    Удалить информацию о синхронизации по всей выборке
    <Ctrl-F8> Удаляет информацию о синхронизации по всей выборке, определенной текущим фильтром. Будьте очень внимательны: не используйте эту функцию, если четко не представляете ее последствий!

    Положить товар в корзину
    <Ctrl-F4> Если текущая строка соответствует объекту “Товар”, то функция позволяет добавить этот товар в выбранную корзину.
    Печать
    <F7> Отправляет на печать выборку анализа синхронизации.

    Итоги
    <F9> Показывает итоги по выборке анализа.
    Фильтр
    <Ctrl-V> Позволяет изменить параметры фильтрации выборки.

    Виды ошибок синхронизации

    0
    Объекты синхронизированы правильно
    1
    В таблице синхронизации не найден общий идентификатор, переданный с объектом для сравнения. Следовательно, в нашей базе данных отсутствует какая-либо информация о синхронизации этого объекта (вероятнее всего, он был создан в другом разделе и к нам никогда не передавался).
    2
    Таблица синхронизации имеет правильные записи по этому объекту, но наименования объектов различаются. Уровень соответствия наименований указан отдельной колонкой в отчете.

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

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

    На человеческом языке это означает примерно следующее “Другой раздел думает о нас не то, что есть на самом деле”. Как правило, это не является большой проблемой. К сожалению, большей проблемой является то, что эта ошибка “маскирует” другие возможные ошибки с кодом 2. То есть, если есть и ошибка 2 и ошибка 3, то в отчете показывается 3.

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

    Конфигурация обмена данными

    Основная конфигурация обмена данными

    Доступ к конфигурации обмена данными возможен через меню Админ→ Прочие конфигурации→ Конфигурация обмена данными.Обращаем ваше внимание на то, что эта конфигурация определяет не все опции обмена данными. Некоторые особенности синхронизации заданы в других разделах конфигурации системы. Символ ! в левой колонки помечает наиболее существенные, с точки зрения воздействия на базу данных, опции.

    Конфигурации обмена данными

    ! ✓Не принимать неполные документы

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

    ✓Рассчитывать итоговой дефицит товаров

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

    ! ✓Приходовать итоговый дефицит

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

    ✓Связывать возвратные документы

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

    ✓Не обрабатывать пакеты подтверждений

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

    ✓Двухпроходная обработка приема

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

    ! ✓Передавать документы списания ревизии

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

    ! ✓Не принимать изменения товаров

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

    Описанная опция не препятствует созданию в вашем разделе базы данных товара, созданного в другом разделе и переданного (возможно вместе с каким-либо иным объектом данным, скажем, товарным документом) к вам.

    ✓Контекстная синхронизация видов операций

    Если флаг установлен, то система, при приеме нового вида операции из другого раздела, прежде чем создать его копию в базе данных, попытается найти контекстный аналог ей. Аналоги ищется по следующим критериям: совпадение имени, совпадение типа операции и совпадение таблицы аналитических статей. В общем случае, можно рекомендовать устанавливать эту опцию, поскольку отрицательные побочные эффекты от нее крайне маловероятны. Когда она действительно необходима, так это в случаи независимого создания одного и того же (по смыслу) вида операции в разных разделах. Если это флаг не будет установлен, то в результате, в каждом из разделов возникнет по два, фактически одинаковых вида операции. Более того, в дальнейшем произойдет “раздвоение” документов, относящихся к этим видам операций.

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

    ! ✓Передавать карточки без чеков

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

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

    ✓Не преобразовывать скидки на документы

    ! ✓Передавать кассовые сессии

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

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

    ✓Упаковывать файл перед отправкой

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

    ✓Игнорировать объединенные объекты

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

    ✓Суммировать дубл строки инвентаризации

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

  • в офисе товары A и B были объединены
  • в магазине ввели документ инвентаризации, в который попали и товар A и товар B
  • инвентаризация передана из магазина в офис
  • так как в документах инвентаризации исключено дублирование одного товара более чем в одной строке, то при приеме в офисе, система выдает сообщение об ошибке. Не смотря на то, что это сообщение весьма “интеллигентное”, (то есть, такая ошибка не препятствует приему документа), офис “не досчитается” в документе одной строки.
  • Если вы установите рассматриваемый флаг, то, возвращаясь к нашему маленькому примеру, система примет строки по т?варам А и Б как одну строку, в которой фактическое количество равно сумме соответствующих значений по строкам оригинального документа.

    !

    Порядок списания

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

  • ○По умолчанию
  • ○FIFO
  • ○LIFO
  • Значение “По-умолчанию” означает, что будет использован порядок списания, заданный в конфигурации. Причина, по которой может понадобиться переопределить порядок списания лотов, кроется в том, что документы из разделов-отправителей могут передаваться не в хронологическом порядке. Например, сначала переданы документы за 20 августа, а потом за 15 августа. В этом случае, если основная конфигурация предполагает порядок списания лотов FIFO, то более поздний расходный документ может “съесть” остаток по лотам, который в разделе-отправителе, использовался для более ранних документов.

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

    ! ▼Все документы принимать на один склад

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

    ▼Вид операции для приходования дефицита

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

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

    ✓Процент наценки для дефицита

    Специальная опция.

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

    ✓Цена реализации равна цене поступления

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

    ✓Подстановка дефицитного товара

    ✓Отложенная фиксация транзакции по умолчанию

    Этот флаг влияет только на диалог приема данных их других разделов. Если он установлен, то в этом диалоге не будет устанавливаться флаг ✓Непосредственная фиксация транзакции.

    ✓Очистка очереди после фиксации по умолчанию

    ✓Не показывать информацию об изменении объектов

    ✓Передавать с тегами прикрепленные файлы

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

    Конфигурация глобального обмена

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

    ▼Почтовая учетная запись

    Параметры Universe-HTT
    URN сервисов Universe-HTT
    Префикс URL сервисов Universe-HTT
    Аккаунт Universe-HTT
    Пароль аккаунта Universe-HTT

    ▼Учетная запись СМС-клиента

    ▼Адрес сервера обмена ЕГАИС

    Параметры EDI

    ▼Вид операции заказа

    ▼Вид операции ORDER

    ▼Вид операции ORDERSP

    ▼Вид операции DESADV

    ▼Вид операции прихода от поставщика через ЕГАИС

    ▼Вид операции возврата от покупателя через ЕГАИС

    ▼Тэг номера документа подтверждения

    ▼Тэг номера TTH

    ✓Не принимать документы с неразрешенными компонентами

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

    ✓Безусловный акцепт внутренних перемещений, продублированных по EDI

    ✓Использовать собственную базу объектов ЕГАИС

    ✓При нахождении аналога документа использовать дату как критерий

    ✓Строгая проверка передаваемых кодов товаров

    [Конфигурация ВЕТИС]

    [Конфигурация MQC]

    OOO "Петроглиф"
    Copyright © 2019