СПОСОБ И СИСТЕМА ПЕРЕДАЧИ ИЗВЕЩЕНИЙ ПОЛЬЗОВАТЕЛЯМ СИСТЕМЫ ДОСТАВКИ Российский патент 2008 года по МПК H04L12/24 G06F13/14 

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

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

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

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

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

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

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

В системе доставки для систем камер для посылок извещения обычно посылают электронной почтой или в виде 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 или LogislicProviderVARCHAR (16)LC_4711, LP_4712, DC_4713CommTypeВид связиVARCHAR (12)SMS, Plaintext (обычный текст), MailHeader, позже возможно HTML-mail (сообщения в формате HTML), пейджер, факсИзвещениеТип извещения, см. Раздел 0VARCHAR(12)BNK1, BNK2, BNK3, BNK3N, BNK4, BNK4N, BNK5, BNK5NLangЯзык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В)

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

Логика DeliveryContract LP-> LC (случай В2В)

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

Очередь запросов на передачу CommunicationRequest

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

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

Записью Comm_Туре посредством значения User (Пользователь) может быть задано, что извещение должно быть послано с помощью вида связи, указанного пользователем. Аналогично, значение User может быть записано для установки языка Lang, если должны использоваться параметры настройки пользователя. Необходима ли, и до какой степени, регистрация записи (состояние=3), зависит от конкретной реализации.

Доступ к базам данных

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

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

- База данных LogisticProvider поставляет информацию о логистическом операторе.

- База данных LogisticContractor поставляет информацию о логистическом подрядчике.

- База данных DeliveryContract поставляет информацию о логистическом подрядчике.

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

- База данных автоматов доставки посылок - поставляет информацию о местоположении автомата доставки посылок, которое идентифицируется идентификатором автомата доставки посылок.

Последовательность операций посылки извещения

Таймер

Извещающий компонент регулярно проверяет все задания в очереди 40 запросов на передачу. Это проверка запускается таймером 41 в извещающем компоненте. Интервал таймера в предпочтительном случае может свободно конфигурироваться.

Communication-Queue-Reader (утилита считывания из очереди запросов на передачу)

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

Выбрать * из communication_request_queue

где State=1 // еще не обработан

и SenDate <now (); // и теперь текущая.

Восстановление объектов

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

Термин User (Пользователь) в этом случае относится или к User, объекту LogisticProvider, или к объекту LogisticContractor. Все эти объекты реализуют общий интерфейс Notifyable (Подлежащий извещению). Он обеспечивает методы, необходимые для посылки извещения соответствующему объекту. В некоторых случаях можно обойтись без объекта Parcel (посылка), если, например, извещение нужно послать независимо от доставки посылок, например, в случае регистрации клиента.

Объект Parcel, в свою очередь, обеспечивает метод, посредством которого может быть получен доступ к автомату доставки посылок, в котором лежит посылка.

Считанные данные объектов содержат данные, которые должны быть переданы (такие как имя, адрес, местоположение автомата доставки посылок), а также данные управления (такие как электронная почта и/или SMS, адрес электронной почты).

Логическая проверка

Запросы на передачу Communication Requests, считанные из очереди 40, проверяются согласно логике 20 В2В DeliveryContract, чтобы увидеть, являются ли они все еще корректными извещениями. Если выполняется только одна единственная проверка, необходимо проверить по данным из базы 80 данных посылок, что посылка еще не получена. Если за это время посылка была получена, извещение будет рассматриваться как "завершенное". С этой целью состояние запроса на передачу Communication Request удаляется из внутренней очереди заданий, которые все еще должны быть обработаны, (состояние устанавливается на 2 = полностью обработанное).

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

Центральный рассылающий компонент

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

Если желателен только один вид связи, то непосредственно вызывается желаемый интерфейс поставщика услуг (SPI - Service Provider Interfaces). Если пользователь желает передать извещение с помощью несколько видов связи, то должны быть приняты меры в случае, если извещение успешно осуществлено с помощью первого вида связи, но не с помощью второго. Тогда попытки использовать этот второй вид связи должны повторяться без использования снова первого вида связи. Для этой цели лучше выпускать для каждого желаемого вида связи дубликат объекта CommunicationRequest и затем передавать его соответствующему интерфейсу поставщика услуг.

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

Индивидуальные виды связи преобразуются через так называемые интерфейсы поставщика услуг (SPI - Service Provider Interfaces). Для каждого вида связи имеется такой интерфейс поставщика услуг (SPI). Каждый интерфейс поставщика услуг вызывается объектом Communication Request (запрос на передачу). Как функция от данных этого объекта создается сообщение электронной почты и/или SMS-сообщение. С этой целью считывается соответствующий шаблон 110 и указатели мест заполнения заменяются информацией, считанной из соответствующей базы данных.

Отсрочка рассылки

Возможное желательное ограничение, имеющее отношение к рассылке извещений, заключается в том, что обработка ночью (например, с 22:00 до 6:00 утра) запрещается полностью или только для SMS-извещений. Если желательно полное прекращение рассылки, то это может быть реализовано, например, посредством таймера. Однако поскольку сообщения электронной почты не причиняют беспокойства, предпочтительно запрещать рассылку ночью только SMS-извещений. С этой целью рассылка прерывается в интерфейсе поставщика услуг SMS, и дата рассылки устанавливается на следующий подходящий срок в пределах допустимого временного окна. При первом случае, когда таймер достигнет этого временного окна, запрос на передачу снова считывается и выполняется.

Проверки на непротиворечивость

Извещающий компонент осуществляет проверку непротиворечивости данных, которые должны быть переданы. Клиент должен быть в клиентской базе 70 данных, а посылка - в базе 80 данных посылок. Если, например, клиент был уже удален, извещение больше не посылают. Кроме того, должна присутствовать информация об автомате доставки посылок (местоположение). Проверяется, правилен ли потенциально адрес получателя (почтовый или номер мобильного телефона) и могут ли все указатели мест заполнения шаблона 110 быть заполнены данными. Кроме того, существующие шаблоны должны иметь определенную непротиворечивость: в зависимости от типа шаблона (которые, в свою очередь, различны с точки зрения языка, вида связи и логики В2В (типа "компания-компания")), в шаблонах должны присутствовать следующие важные поля данных:

Если шаблон отсутствует или если он не имеет никаких соответствующих записей, рассылка прекращается и соответствующее сообщение об ошибках генерируется в файле журнала LOG. Шаблоны должны быть проверены. Если рассылка выполняется посредством SMS, то интеллектуальный механизм может приспосабливать сообщения к максимальной длине 160 символов.

Выполнение рассылки

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

Сохранение результата

Если вся процедура была успешной, то в особенно предпочтительной форме осуществления изобретения запись удаляется из очереди невыполненных заданий, в то время как поле state (состояние) устанавливается на "2". В то же самое время поле даты завершения CompletionDate устанавливается на текущую дату + время дня. Такие записи в очереди 40 передаваемых сообщений далее не обрабатываются. Они должны предпочтительно оставаться доступными в очереди на передачу в течение некоторого периода времени, на случай того, что извещение может оказаться недоставленным.

Ошибка может возникнуть по ряду причин:

- Клиента нет в клиентской базе 70 данных или автомата доставки посылок нет в базе 90 данных автоматов доставки посылок.

- Считанные данные неприемлемы (например, не заполнены полностью).

- Шаблоны ошибочны или не существуют.

- Рассылка извещения невозможна по техническим причинам (после нескольких попыток).

Если происходит ошибка, то значение в поле отсчета попыток RetryCount увеличивается. Если RetryCount превышает заданное значение (это зависит также от частоты таймера), сообщение об ошибках генерируется в файле LOG и, например, инициализируется дополнительная ручная обработка. Это может быть, например, проверка хранимых данных или ручное удаление записей из очереди на передачу. Чтобы избежать того, чтобы попытки этих ошибочных извещений предпринимались снова и снова, состояние устанавливается на "9", как только достигнуто определенное значение RetryCount. Эти извещения не обрабатываются. Кроме того, текущая дата сохраняется как дата прерывания в поле даты завершения ComptetionDate. После устранения ошибки состояние должно быть снова установлено вручную на "1". CompletionDate и RetryCount аналогично должны быть сброшены.

Регулярная очистка

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

Удалить из communication_queue

где state=2и completion_date <текущая дата + 7 днейили state=9и completion_date <текущая дата + 30 дней.

Механизм регистрации

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

Конструктивные предложения и ограничения

Для реализации таймера есть несколько вариантов. Он может быть реализован:

- посредством внутреннего таймера прикладного сервера,

- посредством хрона,

- посредством таймера базы данных или

- посредством другого решения.

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

- JMAPI (Java Message API) - Java-интерфейс прикладного программирования для доступа к службам сообщений,

- JMS,

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

Здесь предпочтительны первые два варианта.

Компоновка

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

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

Объект Parcel

Должен быть предоставлен объект Parcel (Посылка), который предоставляет информацию о посылке, идентифицированной однозначным номером посылки:

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

- Объект Delivery Contract должен быть предоставлен посредством метода.

- Объект Parcel (Посылка) предоставляет метод для доступа к автомату доставки посылок, в котором лежит посылка.

Объект Machine

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

- Методы в этом объекте должны предоставить информацию о местоположении автомата доставки посылок.

Объекты, которые должны быть извещены (подлежащие извещению объекты): User, LogisticProvider и LogisticContractor

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

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

- Должна иметься возможность идентифицировать объект Notifiable посредством однозначного идентификатора. Для этой цели, например, идентификатор объектов User, LogisticProvider и LogisticContractor, конкатенированный с идентификатором типа объекта (US_, LP_, LC_), может быть возвращен методом getUniqueID. Этот метод предпочтительно должен быть определен в интерфейсе Notifyable.

- Чтобы снова воссоздать объект Notifiable посредством этого идентификатора, реализуется Objec Factory (фабрика объектов), которая на основе такого идентификатора создает соответствующий объект.

Логические объекты DeliveryContract, LogisticProvider и LogisticContractor

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

- Такой объект должен идентифицироваться посредством однозначного идентификатора. Для этой цели может использоваться идентификатор объекта Notifiable (getUniqueID), который уже существует для LogisticProvider u LogisticContractor. Соответствующий метод должен также присутствовать в DeliveryContract (Договоре на поставку), который тогда обеспечивает обратную связь, возвращая идентификатор объекта, конкатенированный с идентификатором типа объекта (DC_).

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

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

- Реализация может поддерживать любые (но предпочтительно постоянные) языки.

- Сообщения электронной почты предпочтительно посылают как обычный текст.

Однако особенно предпочтительными формами осуществления изобретения являются следующие:

- Поддержка электронной почты в формате HTML.

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

- Поддержка нескольких языков

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

- Поддержка извещений посредством стандарта RFC1149.

- Кроме того, может использоваться Content Management System (Система управления контентом), чтобы облегчить управление шаблонами для электронной почты и SMS.

Список обозначений

10внешний интерфейс20логика договора поставки30центральный рассылающий компонент40очередь запросов на передачу41таймер50утилита считывания из очереди70база данных клиентов80база данных посылок90автомат доставки посылок100база данных документов110шаблоны120шлюз (межсетевой интерфейс)

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

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