Способ и система передачи извещений пользователям системы доставки

Способ и система передачи извещений пользователям системы доставки

Иллюстрации

Показать все

Реферат

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

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

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

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

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

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

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

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

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

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

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

Кроме того, в патенте США №6047264 описывается способ передачи данных о состоянии партии товаров пользователю, где в центральной базе данных создается запись, когда пользователь заказывает партию товаров. Если состояние партии товаров изменяется, например, когда она передается в доставочную компанию, когда она транспортируется на различные станции или когда она прибывает в пункт назначения, то данные об изменении состояния собираются в базе данных. Этот сбор данных может быть выполнен вручную или электронным путем. Посредством модуля запросов извещающий компонент непрерывно запрашивает изменения состояния из базы данных и создает сообщения для пользователя партии товаров, для которой состояние изменилось. Извещение предпочтительно выполняется электронной почтой.

В международной заявке WO 02/50705 А1 описывается система рассылки электронных документов, таких как сообщения электронной почты. Эти сообщения электронной почты содержат, например, вложения для рекламных целей. Система предназначена для устранения недостатков существующих почтовых систем, например того факта, что отправитель не может получить информацию о том, открыл ли получатель вложение в сообщение электронной почты или имеет ли получатель программное обеспечение, которое необходимо, чтобы открыть файл. Кроме того, она посылает статистическую информацию отправителю, когда получатель открывает электронный документ. Система состоит по существу из генерирующего модуля, который создает главный документ из шаблона и из избранной информации отправителя. Главный документ проверяется и передается передающему модулю, который посылает документ одному или нескольким получателям.

Патент США №6220509 В1 раскрывает систему отслеживания посылок, в которой информация о положении партии груза записывается прямо в клиентскую базу данных. В этом случае клиентская база данных предпочтительно доступна через Web-страницу сети Интернет.

Европейская заявка на патент ЕР 0491367 А2 раскрывает способ обработки сообщений, в котором задания сохраняются в очереди, чтобы выполнять их управляемым образом. Здесь задания могут быть адаптированы к различным условиям и особенностям мест назначения и каналов связи. Способ особенно хорошо подходит для использования в системах электронной почты.

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

Согласно изобретению эта цель достигается так, как изложено в независимых пунктах 1 и 5. Целесообразные формы осуществления изобретения следуют из дополнительных пунктов 2-4.

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

Цель достигается также с помощью системы для осуществления вышеупомянутого способа.

Модули с соответствующими функциями для реагирования на события в системе доставки формируют внешний интерфейс, посредством которого осуществляется преобразование различных Use Cases (случаев использования). В особенно предпочтительном варианте осуществления изобретения задания на извещения, создаваемые модулями, передаются непосредственно рассылающему компоненту только в особых случаях, а как правило они записываются в очередь запросов на передачу Communication Request Queue. Утилита считывания из очереди Queue Reader считывает задания из очереди запросов на передачу под управлением таймера и передает их центральному рассылающему компоненту. При этом предварительно проверяется состояние извещения. Изменение состояния может произойти, например, вследствие того, что посылку уже забрали или изменился забирающий ее человек.

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

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

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

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

На этих чертежах показано следующее:

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

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

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

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

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

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

UC BNK1 подтверждение регистрации клиента

UC BNK2 изменение данных клиента

UC BNK3 извещение "новая посылка"

DC BNK5 извещение "посылка была забрана"

UC BNK6 извещение "посылка послана обратно"

UC BNK7 извещение "добавлено заменяющее лицо"

UC BNK8 извещение "заменяющее лицо удалено"

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

Последовательность и вызов функциональных процедур в модулях объясняются ниже. Задания на извещения, созданные модулями, передаются центральному рассылающему компоненту 30 для немедленной рассылки, или же они вводятся в очередь 40 для рассылки с задержкой по времени. Из этой очереди все ожидающие задания на извещения регулярно считываются, и рассылаются соответствующие извещения. Созданные извещения предпочтительно рассылаются электронной почтой или как SMS-сообщения.

UC BNK1 Подтверждение регистрации

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

newRecipient (User) - новый Получатель (Пользователь)

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

UC BNK2 Изменение клиентских данных

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

updateRecipient (User) - обновить Получателя (Пользователя)

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

UC BNK3 Извещение "новая посылка"

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

notifyDelivery (Parcel) - известить о доставке (Посылка)

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

UC BNK5 Извещение "посылка забрана"

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

notifyPickup (Parcel) - известить о получении (Посылка)

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

UC BNK6 Извещение "посылка послана обратно"

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

parcelFailed (Parcel) - отказ от посылки (Посылка)

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

UC BNK7 Извещение "добавлено заменяющее лицо"

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

addSubstitute (Parcel, User) - добавить заместителя (Посылка, Пользователь)

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

UC BNK8 Извещение "заменяющее лицо удалено"

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

removeSubstitute (Parcel, User) - удалить Заместителя (Посылка, Пользователь)

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

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

Автомат доставки посылок не работоспособен notifyADMFailed

(Parcel parcel, boolean failure)

Извещение общего характера genericNotification

(Parcel parcel, Addressable add, int type)

Извещение для оператора доставки: посылка доставлена

notifyDeliveryProvider (Parcel parcel)

Извещение для оператора доставки: посылка удалена

notifyPickupProvider (Parcel parcel)

Филиал

notifyBranch (String description, DeliveryMachine adm, Addressable recipient, boolean branchCODParcel)

Склад

notifyWarehouseDelivery (Строковое описание, DeliveryMachine adm)

Контроль адресов завершился неудачей

notifyAdressCheckFailed (String description, Addressable recipient)

Пароль Интернет

notifylnternetPassword (String description, Addressable recipient)

Текстовое сообщение общего характера

notifyGenericMessageText (String description, Addressable recipient)

Обратное сообщение оператору о доставке

notifyDeliveryReturnsProvider (Parcel parcel)

Обратное сообщение оператору о получении

notifyPickupReturnsProvider (Parcel parcel)

Получение посылки оператором агента

notifyPickupByDeliveryAgentProvider (Parcel parcel)

Изменение адреса электронной почты

notifyEmailChanged (Addressable recipient)

Изменение номера мобильного телефона

notifyMobileNumberChanged (Addressable recipient)

Изменение почтового PIN-кода

notifyPostPinChanged (Addressable recipient)

Изменение пароля

notifyИнтернетPasswordChanged (Addressable recipient)

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

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

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

Фиг.1 показывает структуру особенно предпочтительной формы выполнения извещающего компонента. Извещающий компонент связан с внешним интерфейсом 10, который получает внешний вызов, когда происходят определенные события системы доставки. Интерфейс сформирован несколькими модулями, каждый с соответствующими функциями. События системы доставки преобразуются в задания на передачу извещений компонентом логики расчетов В2В (типа "компания-компания") (не показан). Для некоторых специальных случаев эти задания могут рассылаться прямо через центральный рассылающий компонент 30. В качестве стандартной процедуры, однако, задания записываются в очередь 40 запросов на передачу и затем передаются центральному рассылающему компоненту 30 под управлением таймера. Это позволяет, например, посылать извещения-напоминания в более поздние моменты времени (например, через 2 дня или 7 дней). Кроме того, запись в очередь имеет то преимущество, что в этом случае автоматически повторяются попытки передачи, потерпевшие неудачу.

Фиг.2 показывает последовательность операций после записи заданий на извещения в очередь 40 запросов на передачу. Задания, стоящие в очереди 40, считываются утилитой 50 считывания из очереди под управлением таймера. Процедура контроля еще раз проверяет, опираясь на логику 20 договора поставки типа "компания-компания", изменилось ли состояние за это время. Изменение состояния происходит, например, когда отданная на хранение посылка была получена или лицо, получающее ее, было изменено. Если проверка правильности была успешной, то запрос на передачу передается рассылающему компоненту 30.

Фиг.3 показывает последовательность операций, связанных с центральным рассылающим компонентом 60. Ход процесса внутри рассылающего компонента обозначен стрелками. Рассылающий компонент принимает задания извне и затем считывает данные, необходимые для передачи извещения, из подключенных баз данных. Эти базы данных включают по меньшей мере одну базу 70 данных клиентов, базу 80 данных посылок и базу 90 данных автоматов доставки посылок. База данных автоматов доставки посылок содержит данные о системах камер для посылок описываемой системы. Затем шаблон 110, заданный компонентом 20 В2В (логики типа "компания-компания"), считывается из базы 100 данных документов, и указатели мест заполнения в шаблоне заменяются текущими данными. Сообщение электронной почты или SMS, созданное таким способом, может быть послано, например, через шлюз 120 электронной почты и SMS.

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

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

Внешний интерфейс

Внешний интерфейс 10 связан с извещающим компонентом и вытекает из различных случаев использования: для каждого случая использования предпочтительно определена собственная функция, которая в пределах извещающего компонента реализует необходимые функциональные возможности. Эти функции соответствуют событиям системы доставки и имеют отношение, например, к объектам "посылка" (parcel) и/или объектам "пользователь" (user). Конечно, функции могут быть расширены и могут касаться также других объектов.

newRecipient (User) - новый Получатель (Пользователь)

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

updateRecipient (User) - обновить Получателя (Пользователь)

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

notifyDelivery (Parcel) - уведомить о доставке (Посылка)

вызывается, когда посылка доставлена в автомат доставки посылок системы доставки.

notifyPickup (Parcel) - уведомить о получении (Посылка)

вызывается, когда посылка была забрана из автомата доставки посылок системы доставки.

parcelFailed (Parcel) - отказ от посылки (Посылка)

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

addSubstitute (Parcel, User) - добавить Заместителя (Посылка, Пользователь)

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

removeSubstitute (Parcel, User) - удалить Заместителя (Посылка, Пользователь)

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

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

Механизм шаблонов

Необходимые шаблоны

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

Регистрация нового клиента	BNK1
Изменение данных клиента	BNK2
Доставка посылок	BNK3, BNK3N
Посылка ожидала в течение 48 часов	BNK4, BNK4N
Посылка будет отослана обратно
через 48 часов	BNK5, BNK5N

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

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

Хранение в базе данных

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

Поле	Описание	Тип	Пример
Contract (Контракт)	Идентификатор DeliveryContract, LogisticPartner или LogislicProvider	VARCHAR (16)	LC_4711, LP_4712, DC_4713
CommType	Вид связи	VARCHAR (12)	SMS, Plaintext (обычный текст), MailHeader, позже возможно HTML-mail (сообщения в формате HTML), пейджер, факс
Извещение	Тип извещения, см. Раздел 0	VARCHAR(12)	BNK1, BNK2, BNK3, BNK3N, BNK4, BNK4N, BNK5, BNK5N
Lang	Язык	VARCHAR (5)	de-Германия en-США
Текст шаблона	Хранимый текст шаблона	VARCHAR (2048)

Следует заметить, что в зависимости от события системы доставки для извещения, ключ базы данных "Contract" может быть Logistic-Provider (Логистический оператор) или Logistic-Contractor (Логистический подрядчик) (в случае BNK1 и BNK2) или же DeliveryContract (контракт на доставку) (в случае BNK3-BNK5).

Механизм указателя места заполнения

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

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

> M_NR<	событие системы доставки - номер клиента
> M_Address<	форма обращения
> MJFirstName<	имя
> M_SurName<	фамилия
> M_SMS<	SMS-номер клиента
> MJVIail<	адрес электронной почты клиента
> M_Street<	улица и номер дома клиента
> M_ZipCode<	почтовый индекс клиента
> M_City<	название населенного пункта клиента
> AUT_Street<	улица и номер дома автомата доставки посылок
> AUT_ZipCode<	почтовый индекс автомата доставки посылок
> AUT_City<	название населенного пункта, где установлен автомат доставки посылок
> POD_Amount<	сумма и валюта наложенного платежа

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

Длина сообщения

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

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

Логика В2В DeliveiyContract

Логика 20 В2В Deliver/Contract (договора поставки типа "компания-компания") определяет, как должна выглядеть индивидуальная бизнес-логика для определенного LogisticProvider, определенного LogisticContractor и определенного Deliver/Contract (между определенным логистическим оператором и определенным логистическим подрядчиком). Для этой цели индивидуальные события преобразуются в задания на передачу извещений. События системы доставки newRecipient и updateRecipient зависят только от LogisticProvider или LogisticContractor, с которыми связан соответствующий пользователь. Другие события системы доставки касаются доставки посылок, то есть они зависят от LogisticProvider (который перевозит посылку) так же, как от LogisticContractor (который определяет получателя или доставщика посылки). Для реализации логики определяется список извещений, которые должны быть посланы (запросы на передачу), для каждого события системы доставки. Эти запросы на передачу включают несколько параметров, которые могут устанавливаться.

События системы доставки

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

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

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

Немедленно	извещение посылается немедленно
+ Х единиц времени	извещение посылается через Х единиц времени
- Х единиц времени	извещение посылают за Х единиц времени до

истечения срока посыпки

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

Предпочтительно существует возможность выбора шаблона 110, который должен использоваться для передачи. Это имеет то преимущество, что различные тексты могут быть использованы в одном и том же договоре поставки, например, для различных событий системы доставки. Кроме того, шаблон всегда дополнительно ограничивается в соответствии с текущим Delivery Contract (Договором на поставку). Таким образом, некоторый шаблон (например, BNK1) может также иметь различное содержание для двух различных договоров поставки. Кроме того, для различных видов связи могут сохраняться различные версии одних и тех же шаблонов.

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

Дифференциация в случае посылок наложенным платежом

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

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

Проверка, была ли получена посылка

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

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

LogisticProvider DPAG (Почта ФРГ) (случай В2С (электронная коммерция типа бизнес - потребитель))

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

Событие системы доставки	Лицо, которое необходимо информировать (Получатель, заместитель, логистический оператор, логистический подрядчик)	Дата: немедленно, + Х дней, - Х дней (до истечения срока)	Вид связи (электронная почта, SMS, user)	Шаблон	Прочее
Новый пользователь	-	-	-	-	-
Пользователь изменен	-	-	-	-	-

LogisticContractor Конечный клиент (случай В2С (электронная коммерция типа бизнес-потребитель))

Следующая таблица - пример, определяющий извещения, которые должны быть посланы (запросы на передачу) при регистрации пользователей для виртуального "конечного клиента" LogisticContractor. Здесь объединены все те пользователи, которые зарегистрированы для случая В2С.

Событие системы доставки	Лицо, которое необходимо информировать (Получатель, заместитель, логистический оператор, логистический подрядчик)	Дата: немедленно, + Х дней, - Х дней (до истечения срока)	Вид связи (электронная почта, SMS, user)	Шаблон	Прочее
Новый пользователь	Получатель	Немедленно	Пользователь	BNK1	Без SMS ночью
Пользователь изменен	Получатель	Немедленно	Пользователь	BNK2	Без SMS ночью

Логика договора поставки - конечный клиент (Случай В2С (электронная коммерция типа бизнес-потребитель))

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

Событие системы доставки	Лицо, которое необходимо информировать (Получатель, заместитель, логистический оператор, логистический подрядчик)	Дата: немедленно, + Х дней, - Х дней (до истечения срока)	Вид связи (электронная почта, SMS, user)	Шаблон	Прочее
Посылка доставлена	Получатель	Немедленно	User (пользователь)	BNK3, BNK3N	Различие в случае посылок наложенным платежом Проверка, была ли посылка получена Без SMS ночью
	Получатель	+ 2 дня	User (пользователь)	BNK4, BNK4N	Различие в случае посылок наложенным платежом Проверка, была ли посылка получена Без SMS ночью
	Получатель	- 2 дня	User (пользователь)	BNK5, BNK5N	Различие в случае посылок наложенным платежомПроверка, была ли посылка получена Без SMS ночью
Посылка получена	-	-	-	-	-
Посылка послана обратно	-	-	-	-	-
Добавлен заместитель	-	-	-	-	-
Заместитель удален	-	-	-	-	-

Логистический оператор LogisticProvider LP (случай В2В)

Событие системы доставки	Лицо, которое необходимо информировать (Получатель, заместитель, логистический оператор, логистический подрядчик)	Дата: немедленно, + Х дней, - Х дней (до истечения срока)	Вид связи (электронная почта, SMS, user)	Шаблон	Прочее
Новый пользователь	-	-	-	-	-
Пользователь изменился	-	-	-	-

Логистический подрядчик LC LogisticContractor (случай В2В)

Событие системы доставки

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