ES2316855T3 - Procedimiento y sistema para la transmision de notificaciones a los usuarios de un siustema logistico. - Google Patents
Procedimiento y sistema para la transmision de notificaciones a los usuarios de un siustema logistico. Download PDFInfo
- Publication number
- ES2316855T3 ES2316855T3 ES03792130T ES03792130T ES2316855T3 ES 2316855 T3 ES2316855 T3 ES 2316855T3 ES 03792130 T ES03792130 T ES 03792130T ES 03792130 T ES03792130 T ES 03792130T ES 2316855 T3 ES2316855 T3 ES 2316855T3
- Authority
- ES
- Spain
- Prior art keywords
- package
- notification
- notifications
- logistics
- queue
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
- G06Q30/0601—Electronic shopping [e-shopping]
- G06Q30/0633—Lists, e.g. purchase orders, compilation or processing
- G06Q30/0635—Processing of requisition or of purchase orders
Landscapes
- Business, Economics & Management (AREA)
- Economics (AREA)
- Engineering & Computer Science (AREA)
- Development Economics (AREA)
- Marketing (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Entrepreneurship & Innovation (AREA)
- Operations Research (AREA)
- Quality & Reliability (AREA)
- Tourism & Hospitality (AREA)
- Human Resources & Organizations (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Information Transfer Between Computers (AREA)
- Eye Examination Apparatus (AREA)
- Traffic Control Systems (AREA)
- Debugging And Monitoring (AREA)
- Warehouses Or Storage Devices (AREA)
- Steroid Compounds (AREA)
- Molding Of Porous Articles (AREA)
- Supports Or Holders For Household Use (AREA)
- Cash Registers Or Receiving Machines (AREA)
Abstract
Sistema logístico con uno o varios sistemas de compartimentos para paquetes y con uno o varios usuarios registrados, comprendiendo el sistema logístico módulos con funciones para la generación de órdenes de notificación, un componente de envío central (30), una cola de petición de comunicación (Communication Request Queue) (40), una base de datos de modelos (100) con plantillas (Templates) (110) para la generación de notificaciones individuales para el usuario correspondiente, una base de datos de clientes (70) con información de clientes, una base de datos de paquetes (80) con información de paquetes, una base de datos de máquinas automáticas (90) con información de los sistemas de compartimentos para paquetes y una pasarela (120) para el envío de las notificaciones, estando equipado el sistema logístico de forma que diferentes incidencias dentro del sistema logístico llaman a diferentes módulos con funciones asociadas para generar ordenes de notificación que se escriben en una cola de petición de comunicación (Communication Request Queue) (40) para el envío directo al componente de envío (30) o para el envío retardado temporalmente, leyendo un lector de cola (Queue Reader) (50) las órdenes de notificación de una cola de petición de comunicación (Communication Request Queue) (40) de forma controlada por temporizador y transmitiéndolas al componente de envío central (30) que genera las notificaciones correspondientes específicas del usuario y las envía a través de una pasarela (120) a los usuarios, y presentando el sistema logístico una lógica de contrato de entrega (Delivery Contract Logic) (20) que valida el estado de las órdenes de notificación antes de la transferencia al componente de envío central (30).
Description
Procedimiento y sistema para la transmisión de
notificaciones a los usuarios de un sistema logístico.
La invención se refiere a un procedimiento para
la transmisión de notificaciones a usuarios de un sistema
logístico, en el que el sistema logístico comprende uno o varios
sistemas de compartimentos para paquetes con uno o varios usuarios
registrados, y en el que las órdenes de notificación se transmiten a
un componente de envío central que a causa de las órdenes genera
notificaciones correspondientes y éstas las envían los usuarios,
accediendo el componente de envío a una o varias bases de datos para
la generación de las notificaciones.
La invención se refiere además a un sistema para
la transmisión de notificaciones a usuarios de un sistema logístico
que gestiona uno o varios sistemas de compartimentos para
paquetes.
Para la gestión de un sistema logístico con una
pluralidad de usuarios y con uno o varios proveedores logísticos
es necesaria la transmisión de determinada información a los
abonados del sistema. La transmisión de información se indica a
continuación como notificación. Notificaciones semejantes pueden
realizarse a través de uno varios métodos de comunicación
diferentes.
Las notificaciones se envían a causa de
incidencias acaecidas dentro del sistema logístico. En este caso una
incidencia del sistema logístico puede provocar ninguna, una o
varias notificaciones. La asignación de incidencias del sistema
logístico a notificaciones puede realizarse dentro de un componente
de notificación en función de una lógica de negocio.
Las notificaciones pueden transmitirse por
diferentes métodos de comunicación. El método de comunicación
representa en este caso la manera como se distribuye una
notificación. Básicamente una notificación puede distribuirse con
el mismo contenido de información mediante varios métodos de
comunicación.
En particular al gestionar un sistema de
compartimentos para paquetes de usuarios registrados por una empresa
de transporte y distribución es necesario un sistema logístico con
diferentes notificaciones y métodos de comunicación. Sistemas o
máquinas automáticas semejantes de compartimentos para paquetes se
gestionan, por ejemplo, por una empresa postal para usuarios
registrados para los que se depositan por un repartidor paquetes u
otros envíos en un compartimento del sistema. Acto seguido al
usuario se le debe notificar sobre el depósito de un paquete para
él. Además, el sistema logístico debe ser informado, por ejemplo,
sobre si un usuario ha recogido su paquete. Dentro del sistema
logístico puede intercambiarse además información sobre el registro
de nuevos clientes, datos de clientes, plazos de recogida e importes
de contra reembolso.
Dentro de un sistema logístico por sistemas de
compartimentos para paquetes las notificaciones se envían
típicamente por e-mail o SMS. La generación,
organización y envío de las notificaciones comprende preferiblemente
diversas bases de datos y desarrollos de los procedimientos.
En el reparto de bienes se conoce el empleo de
sistemas logísticos. Los bienes a repartir pueden ser las más
diferentes mercancías, materiales y objetos. Los sistemas logísticos
sirven para organizar y vigilar el reparto de los correspondientes
bienes, por ejemplo, entre almacenes, almacenes intermedios,
recipientes, vehículos, remitentes y destinatarios a través de
diferentes métodos de transporte. Las funciones de los sistemas
logísticos están adaptadas convenientemente a los requerimientos,
de forma que puede optimizarse el reparto de bienes, por ejemplo,
con vista a los métodos de transporte, tasa de utilización, tiempos
de almacenamiento y transmisión de datos.
La solicitante emplea en particular sistemas
logísticos para el reparto de envíos postales y de mercancías
(pequeños paquetes, paquetes) recipientes de transporte, palés y
contenedores. En este caso los sistemas logísticos concernientes
sirven preferiblemente para el reparto de envíos entre un remitente
y un destinatario, teniendo importancia, por ejemplo, criterios
como rapidez de transporte, empleo de almacenes y vehículos y la
transmisión de datos de envío.
Del modelo de utilidad alemán 201 03 564 U1 se
conoce, por ejemplo, un sistema para la distribución y recepción de
envíos que es apropiado en particular para comercios electrónicos.
El sistema comprende varias máquinas automáticas de salida (ADM) en
las que se depositan y recogen los envíos. El sistema alberga además
un programa informático de servidor LAMIS para el tratamiento de
las operaciones del sistema. El cliente es informado, por ejemplo,
mediante métodos de comunicación como e-mail de los
envíos depositados en la ADM para él.
El documento de patente americana 6,047,264 da a
conocer además un procedimiento para la transmisión del estado de
un envío de un usuario, en el que en la solicitación de un envío por
un usuario se genera una entrada en una base de datos central. Si
el estado del envío cambia, por ejemplo, por la transferencia a una
empresa de reparto, el transporte a diferentes estaciones o por la
entrega en el punto de destino, se registra el cambio de estado en
la base de datos. Este registro puede realizarse de forma manual o
electrónica. Un componente de notificación consulta de forma
continua mediante un módulo de consulta los cambios de estado en la
base de datos y genera mensajes al usuario concerniente de un envío
que ha cambiado el estado. La notificación se realiza
preferiblemente por e-mail.
El registro de patente internacional WO 02/50705
A1 describe un sistema de reparto para documentos electrónicos como
e-mails. Estos e-mails contienen,
por ejemplo, anexos publicitarios. El sistema debe impedir las
desventajas de los sistemas de e-mails que
consisten, por ejemplo, en que un remitente no puede recibir una
información sobre si un destinatario ha abierto el anexo de un
e-mail, o si el remitente no tiene un software
necesario para la apertura de un fichero. Además, se envía
información estadística al remitente si un destinatario ha abierto
un documento electrónico. El sistema consta esencialmente de un
módulo de generación que genera un documento maestro a partir de
una plantilla e información elegible de un remitente. El documento
maestro se comprueba y se transfiere a un modulo de envío que envía
el documento a uno o varios destinatarios.
El documento de patente americana US 6,220,509
B1 da a conocer un sistema de seguimiento de paquetes en el que se
escribe información de estado sobre un envío directamente en la base
de datos de un cliente. El acceso a la base de datos del cliente se
realiza en este caso preferiblemente a través de una página de
Internet.
El registro de patente europea EP 0 491 367 A2
da a conocer un procedimiento para el tratamiento de mensajes, en
el que las órdenes se memorizan en una cola de espera para
realizarse controladamente. En este caso las órdenes pueden
adaptarse a diferentes condiciones y características de los destinos
y uniones de comunicación. El procedimiento es apropiado en
particular para el empleo en un sistema de
e-mails.
El objetivo de la invención es preparar un
sistema logístico que haga posible una respuesta lo más flexible
posible frente a diferentes incidencias dentro de un sistema
logístico y la generación de notificaciones específicas del
usuario. En este caso el sistema logístico debe comprender la
gestión de al menos un sistema electrónico de comportamientos para
paquetes.
Según la invención el objetivo se resuelve por
el objeto de la reivindicación 1 independiente. De las
reivindicaciones dependientes 2 a 3 se deducen formas de
realización ventajosas de la invención.
Según la invención se propone un sistema
logístico con uno o varios sistemas de compartimentos para paquetes
y con uno o varios usuarios registrados. El sistema logístico
comprende módulos con funciones para la generación de órdenes de
notificación, un componente de envío central, una cola de petición
de comunicación (Communication Request Queue), una base de datos de
modelos con plantillas (Templates) para la generación de
notificaciones individuales para el usuario correspondiente, una
base de datos de clientes con información de clientes, una base de
datos de paquetes con información de paquetes, una base de datos de
máquinas automáticas con información de los sistemas de
compartimentos para paquetes y una pasarela para el envío de las
notificaciones. El sistema logístico está equipado de forma que
diferentes incidencias dentro del sistema logístico llaman a
diferentes módulos con funciones asociadas para generar órdenes de
notificación que se escriben en una cola de petición de
comunicación para el envío directo al componente de envío o para el
envío retardado temporalmente. Un lector de cola (Queue Reader) lee
las órdenes de notificación de una cola de petición de comunicación
de forma controlada por temporizador y las transmite al componente
de envío central que genera las notificaciones correspondientes
específicas del usuario y las envía a través de una pasarela a los
usuarios. El sistema logístico presenta una lógica de contrato de
entrega (Delivery Contract Logic) que valida el estado de las
órdenes de notificación antes de la transferencia al componente de
envío central.
El objetivo se resuelve además por un sistema
para la realización del procedimiento.
Los módulos con las funciones correspondientes
para la respuesta a incidencias dentro del sistema logístico forman
un interface externo a través del que se reproducen los diferentes
casos de utilización. En un ejemplo de realización especialmente
preferido de la invención, las órdenes de notificación generadas por
los módulos solo se transmiten en casos especiales directamente al
componente de envío, mientras que en general se apuntan en una cola
de petición de comunicación. Un lector de cola lee las órdenes de la
cola de petición de comunicación de forma controlada por
temporizador y las transmite al componente de envío central. En este
caso se realiza anteriormente una verificación del estado de la
notificación. Un cambio de estado puede realizarse, por ejemplo,
porque un paquete ha sido recogido entre tanto o ha cambiado la
persona que lo recoge.
Según un aspecto de la invención, el componente
de envío genera las notificaciones en virtud de datos de una o
varias bases de datos. Estas bases de datos son convenientemente al
menos una base de datos de clientes, una base de datos de paquetes,
una base de datos de máquinas automáticas y una base de datos de
modelos. La base de datos de clientes contiene, por ejemplo, datos
sobre los clientes registrados del sistema logístico, obteniendo el
cliente correspondiente una ID para la identificación. Estos datos
pueden comprender direcciones, números de teléfono u otros. La base
de datos de paquetes incluye información de los paquetes que se
transportan dentro del sistema, siendo identificados los paquetes
igualmente a través de una ID. La base de datos de máquinas
automáticas incluye información de los sistemas de compartimentos
para paquetes que se emplean dentro del sistema. Este comprende
igualmente IDs.
La base de datos de documentos incluye
plantillas para la generación de notificaciones específicas del
usuario. Incluye para ello preferiblemente plantillas para
notificaciones por e-mail y SMS. Las plantillas
presentan espacios en los que se introducen los datos específicos
del usuario de la base de datos.
Las notificaciones generadas se transmiten a una
pasarela por el componente de envío para el envío al usuario.
Otras ventajas, particularidades y ampliaciones
convenientes de la invención se deducen de las reivindicaciones
dependientes y de la representación siguiente de ejemplos de
realización preferidos mediante las ilustraciones.
\global\parskip0.950000\baselineskip
Por las ilustraciones se muestra:
Fig. 1 los desarrollos del procedimiento entre
un interface externo, un componente de envío central y una cola de
petición de comunicación de un ejemplo de realización especialmente
preferido;
Fig. 2 unos desarrollos del procedimiento entre
una cola de petición de comunicación, un componente de envío
central y una lógica de contrato de entrega de un ejemplo de
realización especialmente preferido;
Fig. 3 los desarrollos del procedimiento entre
un componente de envío central, diferentes bases de datos y una
pasarela; y
Fig. 4 un resumen global sobre los desarrollos
dentro del sistema para la transmisión de notificaciones.
A continuación se describe un sistema logístico
para la gestión de un sistema con uno o varios sistemas de
compartimentos para paquetes y con un número variable de usuarios
registrados. En este caso se trata de un ejemplo de realización
especialmente preferido, no obstante, el procedimiento según la
invención es apropiado también para otros sistemas logísticos en
los que se envían notificaciones.
El sistema logístico para la gestión de uno o
varios sistemas de compartimentos para paquetes se divide a causa
de las funciones, por ejemplo, en al menos los siguientes procesos
de tratamiento:
- UC BNK1
- confirmación del registro de un cliente
- UC BNK2
- cambio de los datos del cliente
- UC BNK3
- notificación "nuevo paquete"
- UC BNK5
- notificación "paquete ha sido recogido"
- UC BNK6
- notificación "paquete ha sido devuelto"
- UC BNK7
- notificación "representante designado"
- UC BNK8
- notificación "representante suprimido"
Para las incidencias mencionados dentro del
sistema se mandan notificaciones al usuario que le informan sobre
la incidencia y/o se lo confirman. La realización de los procesos
individuales de tratamiento se realiza, en un ejemplo de
realización especialmente preferido de la invención, por diferentes
módulos y/o unidades del sistema logístico. Los módulos pueden ser,
por ejemplo, una base de datos de clientes, unidad de registro o
unidad de administración del sistema logístico. Los módulos forman
dado el caso junto con otros componentes un interface 10
externo.
El desarrollo y la llamada de funciones dentro
de los módulos se explican a continuación. Las órdenes de
notificación generadas por los módulos se transfieren para el envío
directo a un componente de envío central 30 o se leen en una cola
de petición de comunicación 40 para el envío retrasado
temporalmente. De esta cola se leen regularmente todas las órdenes
de notificación en espera y se envían las notificaciones
correspondientes. Las notificaciones generadas se envían
preferiblemente como e-mail o SMS.
Después del registro de un nuevo cliente para el
sistema logístico de los sistemas de compartimentos de paquetes, un
módulo de registro llama una función newRecipient (usuario) para el
envío de una notificación de confirmación. La función determina las
notificaciones necesarias a partir de una lógica de mandatos
asignada al cliente y las inscribe en una cola de petición de
comunicación para el envío retrasado temporalmente.
Después de que un cliente ha cambiado sus datos
de cliente consignados en una base de datos de clientes, la base de
datos de clientes llama una función updateRecipiente (usuario) para
el envío de una notificación de confirmación. Esta función
determina igualmente las notificaciones necesarias a partir de una
lógica de mandatos asignada al cliente y las inscribe en una cola
de petición de comunicación para el envío retrasado
temporalmente.
Si se entrega un paquete en una máquina
automática de paquetes del sistema logístico se envía una
información correspondiente a una unidad de administración del
sistema logístico. La unidad de administración del sistema
logístico llama una función notifyDelivery (paquete) para el envío
de una notificación de confirmación. La función determina las
notificaciones necesarias a partir de una lógica de mandatos
asignada al cliente y las inscribe en una cola de petición de
comunicación para el envío retrasado temporalmente.
\global\parskip1.000000\baselineskip
Si un paquete ha sido recogido de una máquina
automática de paquetes del sistema logístico se envía una
información correspondiente a la unidad de administración del
sistema logístico. La unidad de administración del sistema
logístico llama acto seguido una función notifyPickup (paquete) para
el envío de una notificación de confirmación. La función determina
las notificaciones necesarias a partir de una lógica de mandatos
asignada al cliente y las inscribe en una cola de petición de
comunicación.
Si un paquete ha sido devuelto de una máquina
automática de paquetes del sistema logístico porque no ha sido
recogido durante un plazo de recogida determinado, se envía una
información correspondiente a la unidad de administración del
sistema logístico. La unidad de administración del sistema logístico
llama una función parcelFailed (paquete) para el envío de una
notificación de confirmación. La función determina las
notificaciones necesarias a partir de una lógica de mandatos
asignada al cliente y las inscribe en una cola de petición de
comunicación.
Si para un paquete en espera ha sido designado
un representante en una máquina automática de paquetes del sistema
logístico, se envía una información correspondiente a la unidad de
administración del sistema logístico. La unidad de administración
del sistema logístico llama acto seguido una función addSubstitute
(paquete, usuario) para el envío de una notificación de
confirmación. La función determina las notificaciones necesarias a
partir de una lógica de mandatos asignada al cliente y las inscribe
en una cola de petición de comunicación.
Si para un paquete en espera ha sido suprimido
un representante en una máquina automática de paquetes del sistema
logístico, se envía una información correspondiente a la unidad de
administración del sistema logístico. La unidad de administración
del sistema logístico llama una función removeSubstitute (paquete,
usuario) para el envío de una notificación de confirmación. La
función determina las notificaciones necesarias a partir de una
lógica de mandatos asignada al cliente y las inscribe en una cola de
petición de comunicación.
Adicionalmente pueden ilustrarse, por ejemplo,
las siguientes incidencias mediante funciones dentro de los
módulos:
\hskip0.03cm
\vskip1.000000\baselineskip
Las notificaciones se envían preferiblemente en
forma de e-mail o SMS. Para ello puede emplearse,
por ejemplo, una pasarela de e-mails y SMS.
Al emplear un procedimiento según la invención
en la práctica se ha demostrado como conveniente que la lista de
las notificaciones no enviables se repase regularmente (por ejemplo,
cada 24 h.) de forma manual.
Las ilustraciones en las figuras 1 a 4 muestran
un resumen sobre los componentes parciales más importantes de un
ejemplo de realización especialmente preferido del sistema según la
invención. Los sistemas externos están caracterizados sombreados,
mientras que las partes correspondientes al sistema de notificación
están representadas en blanco.
De la ilustración en la fig. 1 se deduce la
estructura de un ejemplo de realización especialmente preferido de
un componente de notificación. El componente de notificación está en
contacto con un interface 10 externo que se llama desde fuera en el
caso de incidencias determinados acaecidos del sistema logístico. El
interface se forma por varios módulos con funciones
correspondientes. Las incidencias del sistema logístico se
convierten en órdenes de notificación a través de un componente con
lógica de cuenta B2B no representado. Para determinados casos
especiales estas órdenes pueden enviarse directamente a través de un
componente de envío central 30. No obstante, de forma estandarizada
se escriben las órdenes en una cola de petición de comunicación 40 y
desde allí se transfieren de forma controlada por temporizador al
componente de envío 30. Esto permite, por ejemplo, la definición de
notificaciones de recordatorio en momentos posteriores (por ejemplo,
después de 2 días o 7 días). La inscripción en la cola tiene además
la ventaja de que aquí se realiza una repetición automática de los
envíos que han fallado.
De la ilustración en la fig. 2 puede deducirse
el desarrollo del procedimiento según el certificado de las órdenes
de notificación en la cola de petición de comunicación 40. Las
órdenes presentes en la cola de petición de comunicación 40 se leen
por un lector de cola 50 de forma controlada por temporizador. Se
supervisa nuevamente frente a una lógica de contrato de entrega B2B
20 si se ha cambiado el estado entre tanto. Un cambio de estado se
realiza, por ejemplo, porque se ha recogido un paquete depositado o
se ha cambiado la persona que lo recoge. Si la validación fue
exitosa se transfiere para el envío una petición de comunicación al
componente de envío 30.
En la ilustración en la fig. 3 está representado
el desarrollo del procedimiento en relación con el componente de
envío central 30. El flujo de proceso dentro del componente de envío
se representa por flechas. El componente de envío obtiene las
órdenes desde fuera y lee acto seguido los datos necesarios para la
transmisión de la notificación de las bases de datos conectadas.
Las bases de datos son al menos una base de datos de clientes 70,
una base de datos de paquetes 80 y una base de datos de máquinas
automáticas 90. La base de datos de máquinas automáticas incluye
datos de los sistemas de compartimentos para paquetes del sistema.
Luego se lee una plantilla 110 predeterminada por el componente B2B
20 de la base de datos de modelos 100 y se reemplazan los espacios
dentro de la plantilla por los datos actuales. El
e-mail o SMS generado así puede enviarse, por
ejemplo, a través de una pasarela de e-mails y SMS
120.
En la ilustración de la fig. 4 se resumen las
tres partes del componente de notificación en un resumen conjunto.
En este caso se ve claramente la separación entre el componente de
envío central 30 en la parte derecha y las partes del componente
lógico del negocio en el lado izquierdo.
A continuación se explican detalladamente los
componentes individuales del sistema y su función dentro de un
ejemplo de realización especialmente preferido del procedimiento
según la invención.
\vskip1.000000\baselineskip
El interface 10 externo está en contacto con el
componente de notificación y resulta sencillamente de diferentes
casos de utilización: para cada caso de utilización se define
preferiblemente una función propia que realiza la funcionalidad
necesaria dentro del componente de notificación. Estas funciones se
corresponden con las incidencias del sistema logístico y
conciernen, por ejemplo, a objetos de paquete (parcel) y/o de
usuario (user). Las funciones naturalmente pueden ampliarse y
pueden referirse también a otros objetos.
newRecipient (usuario)
se llama después del registro de un cliente.
\vskip1.000000\baselineskip
updateRecipiente (usuario)
se llama después de que un cliente ha cambiado
sus datos de cliente consignados en la base de datos de
clientes.
\vskip1.000000\baselineskip
notifyDelivery (paquete)
se llama si un paquete ha sido entregado a una
máquina automática de paquetes del sistema logístico.
\vskip1.000000\baselineskip
notifyPickup (paquete)
se llama si un paquete ha sido recogido de una
máquina automática de paquetes del sistema logístico.
\vskip1.000000\baselineskip
parcelFailed (paquete)
se llama si un paquete ha sido devuelto de una
máquina automática de paquetes del sistema logístico porque no ha
sido recogido dentro de un determinado plazo de recogida.
\vskip1.000000\baselineskip
addSubstitute (paquete, usuario)
se llama si ha sido designado un representante
para un paquete en espera en una máquina automática de paquetes del
sistema logístico.
\vskip1.000000\baselineskip
removeSubstitute (paquete, usuario)
se llama si ha sido suprimido un representante
designado para un paquete que espera en una máquina automática de
paquetes del sistema logístico.
\vskip1.000000\baselineskip
Los objetos de paquete o usuario concernientes
contienen cada vez métodos. Internamente se convierte la incidencia
del sistema logístico en notificaciones que se guardan temporalmente
en la cola 40 interna. Los métodos devuelven como resultado si ha
funcionado o no esta conversión y almacenamiento intermedio.
\vskip1.000000\baselineskip
Pueden enviarse diferentes tipos de
notificaciones, para las que se ha demostrado como conveniente
suministrar plantillas 110 y memorizar éstas en una base de datos
de modelos. Los tipos de notificaciones se ilustran mediante un
nombre de plantilla que clasifica las plantillas en el plano del
contenido de información de la notificación. Para el caso B2C se
necesitan, por ejemplo, las siguientes plantillas:
- Registro de nuevo cliente
- BNK1
- Cambio de datos de cliente
- BNK2
- Entrega de paquete
- BNK3, BNK3N
- Paquete espera desde hace 48 h
- BNK4, BNK4N
- Paquete se devuelve en 48 horas
- BNK5, BNK5N
\vskip1.000000\baselineskip
Para los tres últimos tipos de notificaciones de
paquetes pueden enviarse variantes de plantillas para paquetes con
pago contra reembolso y paquetes sin pago contra reembolso. Junto al
nombre las plantillas pueden identificarse ulteriormente mediante
el contrato de entrega, el método de comunicación y el idioma. Junto
a las plantillas descritas pueden emplearse naturalmente
discrecionalmente muchas otras plantillas.
Para notificaciones completas deben existir
plantillas tanto para el envío de SMS como también para el envío de
e-mails. Para el envío de e-mails se
necesitan preferiblemente plantillas tanto para el texto del
mensaje, como también para la línea de asunto.
\vskip1.000000\baselineskip
Para el mantenimiento más sencillo de las
plantillas 110 éstas se archivan en una base de datos 100. En un
ejemplo de realización especialmente preferido de la invención, esta
base de datos comprende varios campos que están representados a
continuación en forma de tabla:
\vskip1.000000\baselineskip
\newpage
Hay que considerar que la clave de base de datos
"Contract", en función de la incidencia del sistema logístico
a notificar, puede ser un proveedor logístico o un contratista de
logística (en BNK1 y BNK2) o también un contrato de entrega (en
BNK3 - BNK5).
\vskip1.000000\baselineskip
Se ha demostrado como conveniente utilizar
diferentes espacios dentro de las plantillas 110 para sustituir
información concreta. Con vista a un uso de e-mails
con formato HTML deben definirse estos espacios convenientemente no
como etiquetas HTML.
Al menos pueden estar previstos los siguientes
espacios:
- >M_NR<
- Incidencia del número de cliente del sistema logístico
- >M_Adresse<
- Encabezamiento
- >M_FirstName<
- Nombre
- >M_SurName<
- Apellido
- >M_SMS<
- Número de SMS del cliente
- >M_Mail<
- Dirección e-mail del cliente
- >M_Street<
- Calle y número del cliente
- >M_ZipCode<
- Código postal del cliente
- >M_City<
- Nombre de la población del cliente
\vskip1.000000\baselineskip
- >AUT_Street<
- Calle y número de la máquina automática
- >AUT_ZipCode<
- Código postal de la máquina automática
- >AUT_City<
- Nombre de la población de la máquina automática
\vskip1.000000\baselineskip
- >POD_Amount<
- Importe del cobro contra reembolso y moneda
\vskip1.000000\baselineskip
Junto a los espacios descritos pueden emplearse
naturalmente otros espacios.
La longitud máxima de los mensajes SMS es
típicamente de 160 caracteres. Puesto que información consabida,
como emplazamiento de la incidencia de la máquina automática del
sistema logístico, puede tener longitudes variables, los campos muy
largos (por ejemplo, calles o lugares con indicación del barrio)
pueden conducir a "sobrepasar" los 160 caracteres. Para evitar
un "sobrepaso" semejante, en un ejemplo de realización
especialmente preferido de la invención se emplea un mecanismo
inteligente que contiene a ser posible toda la información
esencial, en función de las longitudes individuales de los campos,
de la importación de los campos correspondientes y de la longitud
restante disponible.
Una alternativa a un mecanismo inteligente está
representada por el almacenamiento de versiones cortas de todos los
campos en las bases de datos correspondientes, con lo cual no se
sobrepasa nunca la longitud máxima de 160 caracteres. Pero esto
tiene la desventaja de que las plantillas cambiantes de los SMS
traen consigo nuevas limitaciones de longitud. Así una información
consabida, como la dirección introducida del cliente, no puede
adaptarse
fácilmente.
fácilmente.
La lógica de contrato de entrega B2B 20
determina que aspecto debe tener la lógica de negocio individual
para un proveedor de logística determinado, un contratista de
logística determinado y un contrato de entrega determinado (entre
un proveedor de logística determinado y un contratista de logística
determinado). Para ello las incidencias individuales se convierten
en órdenes de notificación. Las incidencias del sistema logístico
newRecipient y updateRecipient dependen solo del proveedor de
logística o del contratista de logística a los cuales está asignado
el usuario correspondiente. Las otras incidencias del sistema
logístico están en relación con la entrega de paquetes, dependen
tanto del proveedor de logística (que transporta el paquete) como
también del contratista de logística (que define el destinatario o
emisor del paquete). Para la conversión de la lógica se define para
cada incidencia del sistema logístico una lista de notificaciones a
enviar (petición de comunicación). Estas incluyen varios parámetros
que pueden
ajustarse.
ajustarse.
Para cada incidencia pueden estar memorizadas
varias notificaciones si se realizan, por ejemplo, múltiples
notificaciones repetidas o si deben informarse a varias personas con
diferentes papeles.
Las personas a informar son aquellas personas
que deben ser notificadas. Valores posibles son: destinatario,
representante, proveedor de logística o contratista de
logística.
Se determina una fecha en la que debe enviarse
la notificación. En la lógica se archiva solo una fecha relativa,
ésta se compensa luego con la fecha de la incidencia del sistema
logístico hasta una fecha absoluta. Valores posibles para ello son,
por ejemplo:
- Inmediatamente
- el envío de la notificación se realiza inmediatamente
- + X unidades de tiempo
- el envío se realiza en X unidades de tiempo
- - X unidades de tiempo
- el envío se realiza X unidades de tiempo antes del vencimiento del paquete.
\vskip1.000000\baselineskip
Puede predeterminarse un método de comunicación
determinado. Esto se necesita, por ejemplo, si una lógica
determinada prevé sólo notificaciones por SMS. Valores posibles son
e-mail, SMS y usuario (el método de
comunicación indicado para el usuario). Por ello puede ilustrarse,
por ejemplo, una lógica de contrato de entrega que permite las
notificaciones exclusivamente a través de un método de comunicación
determinado.
Preferiblemente existe la posibilidad de la
elección de una plantilla 110 que debe usarse para la transmisión.
Esto tiene la ventaja de que pueden hacerse utilizables diferentes
textos dentro del mismo contrato de entrega, por ejemplo, para
diferentes incidencias del sistema logístico. La plantilla se limita
adicionalmente siempre por el contrato de entrega actual. Una
plantilla determinada (por ejemplo, BNK1) puede tener también
diferentes contenidos así para dos contratos de entrega diferentes.
Además, pueden ponerse delante diferentes versiones de las mismas
plantillas para los diferentes métodos de comunicación.
Además, puede archivarse información adicional
que puede necesitarse para la diferenciación dentro de la lógica de
negocio o en una supervisión posterior de la lógica, como la
información posible representada a continuación:
Aquí se utiliza otra plantilla para paquetes con
importe designado de pago contra reembolso. Esta plantilla incluye,
por ejemplo, el importe del pago contra reembolso como información
para la persona que lo recoge.
Hay procesos B2B en los que está presente un
importe de pago contra reembolso en el paquete, pero este importe
no se transmite a la persona que lo recoge puesto que el pago contra
reembolso se descuenta, por ejemplo, de una cuenta colectiva.
Aquí debe supervisarse si un paquete se
encuentra todavía en la máquina automática del sistema logístico o
si ha sido recogido entre tanto. Esto es útil en particular si se
envían notificaciones de recordatorio, por ejemplo, después de
varios días.
El objeto de paquete debe preparar un
método que devuelva la fecha de vencimiento en la que el paquete
debe retirarse de la máquina automática de paquetes. Esto se
necesita para poder transmitir notificaciones X días antes del
vencimiento. Si no debe ponerse una fecha de vencimiento puede
adoptarse de forma estandarizada un número consabido de días.
\newpage
La tabla siguiente define a modo de ejemplo las
notificaciones a enviar (petición de comunicación) por el registro
de usuarios para un proveedor de logística. En este caso se trata de
repartidores, no se envían notificaciones.
\vskip1.000000\baselineskip
La tabla siguiente define a modo de ejemplo las
notificaciones a enviar (petición de comunicación) por el registro
de usuarios para un contratista de logística virtual "cliente
final". Aquí se resumen todos los usuarios que se registran para
el caso B2C.
\newpage
La tabla siguiente define a modo de ejemplo las
notificaciones a enviar (peticiones de comunicación) para la lógica
B2C entre un proveedor de logística y el cliente final:
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
Se necesita una tabla propia de la base de datos
en la que se guardan temporalmente las órdenes para las
notificaciones a enviar (peticiones de comunicación). La tabla debe
servir preferiblemente solo para la administración de la cola, la
información concreta de los paquetes y destinatarios se lee, por
ejemplo, respectivamente siempre de la base de datos de clientes 70
o de la base de datos de paquetes 80.
\vskip1.000000\baselineskip
No obstante, puede ser conveniente ampliar los
campos de la cola de petición de comunicación. Por ejemplo, pueden
grabarse los números de la máquina automática y la descripción de
texto libre. Por ello no están vinculadas las notificaciones
exclusivamente a los paquetes, sino dado el caso, también a
combinaciones de números postales, incidencias y números de
máquinas automáticas. Además, existe la posibilidad de generar
notificaciones
dinámicamente.
dinámicamente.
Con la entrada Comm_Type puede
predeterminarse a través de un valor usuario que la
notificación debe realizarse a través de métodos de comunicación
predeterminados por el usuario. El valor usuario puede
inscribirse analógicamente para la configuración del idioma
Lang si deben utilizarse las configuraciones del usuario. Si
y en que medida es necesario un registro de una entrada (estado = 3)
depende de la implementación concreta.
Debe prepararse acceso a las siguientes bases de
datos del sistema logístico:
\bullet Base de datos de clientes suministra
información de un cliente, identificado por el número de
cliente.
\bullet Base de datos de proveedores de
logística suministra información de un proveedor de logística.
\bullet Base de datos de contratistas de
logística suministra información de un contratista de logística.
\bullet Base de datos de contratos de entrega
suministra información de un contrato de logística.
\bullet Base de datos de paquetes suministra
información de un paquete, identificado por un número de paquete
unívoco.
\bullet Base de datos de máquinas automáticas
suministra información sobre el emplazamiento de una máquina
automática, identificada por la ID de la máquina automática.
El componente de notificación supervisa
regularmente todas las órdenes en la cola de comunicación 40. Esto
se provoca por un temporizador 41 dentro del componente de
notificación. El intervalo de temporización puede configurarse
preferiblemente de forma libre.
Con la llamada de la función de temporizador se
leen todas las entradas de la cola de petición de comunicación 40
cuya fecha de envío se encuentra detrás de la fecha.
Cada entrada leída de la cola se convierte en un
objeto de petición de comunicación. Mediante la ID unívoca para el
usuario a informar (RecipientID) y la ID para el paquete (ParcelID)
se reconstruyen los objetos parciales correspondientes. Esto es
necesario para poder consultar los datos actuales de los objetos,
como por ejemplo, la dirección de e-mail.
Con usuario se indica en este caso un
usuario, un objeto de proveedor de logística o de
contratista de logística. Todos estos objetos implementan un
interface común notificable. Esto prepara los métodos
necesarios para el envío de una notificación al objeto
correspondiente. El objeto de paquete puede suprimirse
eventualmente si, por ejemplo, debe enviarse una notificación
independientemente del suministro de paquetes, por ejemplo, en un
registro de clientes.
El objeto de paquete prepara de nuevo un
método mediante el que puede accederse a la máquina automática en
el que se encuentra el paquete.
Los datos leídos de los objetos son por un lado
datos a transmitir (como nombre, dirección, emplazamiento de la
máquina automática de paquetes) como también datos de control (como
e-mail y/o SMS, dirección de
e-mail).
Las peticiones de comunicación leídas de la cola
40 se comprueban frente a la lógica de contrato de entrega B2B 20
si todavía son notificaciones vigentes. Si solo se realiza una
supervisión única debe asegurarse frente a los datos de la base de
datos de paquetes 80 que el paquete no ha sido recogido todavía. Si
el paquete ha sido recogido en el tiempo intermedio se considera la
notificación como "realizada". Para ello se quita el estado de
la petición de comunicación de la cola interna de las órdenes a
tratar (el estado se pone en 2 = terminado).
Si el paquete no existe en la base de datos de
paquetes 80 se parte de que entre tanto ha sido recogido, la
respuesta de comunicación se quita igualmente de la lista interna de
las órdenes a tratar.
Las notificaciones se transfieren al componente
de envío central 30. Allí se determina mediante el método de
comunicación indicado en la petición de comunicación y las
configuraciones del usuario con que método de comunicación debe
distribuirse la notificación. En este caso puede producirse
eventualmente un fallo si a través de la lógica de negocio
(Business Logic) se predetermina un método de comunicación
determinado, pero el usuario no apoya este método de
comunicación.
En caso de que se desee solo un método de
comunicación se llama directamente el SPI deseado (Interfaces de
proveedores de servicios, Service Provider Interfaces). En caso de
que el usuario desee una notificación mediante varios métodos de
comunicación deben tomarse medidas para que la notificación tenga
éxito mediante el primer método de comunicación, pero no mediante
el segundo. Luego debe intentarse de forma repetida este segundo
método de comunicación sin que se emplee nuevamente el primer método
de comunicación. Para ello lo más favorablemente se propone para
cada método de comunicación deseado un duplicado del objeto de
petición de comunicación que se transfiere entonces a los
SPI correspondientes.
Los métodos de comunicación únicos se ilustran a
través de, así llamados, SPI's (Interfaces de proveedores de
servicios, Service Provider Interfaces). Para cada método de
comunicación hay un SPI semejante. Cada SPI se llama con el objeto
de petición de comunicación. En función de los datos en este objeto
se suministra un e-mail y/o SMS. Para ello se lee
la plantilla 110 adecuada, y los espacios se sustituyen por la
información leída de la base de datos correspondiente.
Una limitación posible deseada del envío de las
notificaciones es impedir el tratamiento durante la noche (por
ejemplo, 22:00 - 8:00) completamente o solo para notificaciones por
SMS. Si se desea un ajuste completo del envío puede realizarse
esto, por ejemplo, a través del temporizador. Además, puesto que los
e-mails no provocan perturbaciones es más favorable
impedir solo el envío de SMS durante la noche. Para ello se
desconecta el envío dentro del SMS-SPI y la fecha
de envío se pone en la próxima fecha adecuada dentro de la ventana
de tiempo. Con el primer paso del temporizador dentro de ésta
ventana de tiempo se lee y realiza nuevamente la petición de
comunicación.
comunicación.
El componente de notificación realiza una prueba
de plausibilidad de los datos a transmitir. El cliente debe existir
en la base de datos de clientes 70 y el paquete en la base de datos
de paquetes 80. Si un cliente, por ejemplo, está ya borrado ya no
se envía una notificación. Además, debe existir información de las
máquinas automáticas de paquetes (establecimiento). Se supervisa si
la dirección de destinatario (e-mail o número de
móvil) es correcta potencialmente, y si todos los espacios de la
plantilla 110 pueden llenarse con datos. Además, las plantillas
existentes deben presentar una plausibilidad consabida: en función
del tipo de plantilla (esta varia de nuevo en el idioma, el método
de comunicación y la lógica B2B) deben estar presentes en las
plantillas los campos de datos importantes siguientes:
\newpage
Si una plantilla no estuviera presente o no
presentara entradas correspondientes, el envío se interrumpe y se
genera una aviso de fallo correspondiente en un ficho LOG. Las
plantillas deberían supervisarse. En caso de que un envío se
realice por SMS, un mecanismo inteligente puede convertir el mensaje
a una longitud máxima de 160 caracteres.
\vskip1.000000\baselineskip
Con el mecanismo descrito en el párrafo de
mecanismo de plantilla se genera el texto a enviar. El texto
y la información del destinatario se transmiten en función del tipo
de envío a una pasarela de e-mails o de SMS 120. Si
la transmisión a la pasarela fallara puede intentarse una segunda
transmisión inmediata para poder superar fácilmente fallos a corto
plazo.
\vskip1.000000\baselineskip
Si fue exitoso el proceso global la entrada se
borra de la cola de las órdenes atrasadas en un ejemplo de
realización especialmente preferido de la invención, mientras que el
campo State se pone en "2". Al mismo tiempo el campo
CompletionDate se pone en la fecha + hora actuales. Entradas
semejantes en la cola de comunicación 40 no se tratan
ulteriormente. Convenientemente deberían permanecer disponibles un
tiempo consabido en la cola de comunicación si se sacase una
notificación como no entregables.
Un fallo puede aparecer por varios motivos:
\bullet El cliente no está en la base de datos
de clientes 70 o la máquina automática no está en la base de datos
de máquinas automáticas 90.
\bullet Los datos leídos no son plausibles
(por ejemplo, no llenados completamente)
\bullet Las plantillas son defectuosas o no
existen
\bullet Un envío de la notificación no es
posible por motivos técnicos (después de varios intentos).
\vskip1.000000\baselineskip
Si ocurre un fallo se aumenta el campo
"RetryCount". Si el RetryCount ha sobrepasado un valor
predefinido (esto es también independiente de la frecuencia del
temporizador), se genera un aviso de fallo en un fichero LOG y, por
ejemplo, se inicia un tratamiento subsiguiente manual. Esto puede
ser, por ejemplo, la comprobación de los datos memorizados o la
supresión manual de entradas de la cola de comunicación. Para evitar
que esta notificación fallida se intente siempre de nuevo, el
estado se pone en "9" tan pronto como se haya conseguido un
RetryCount consabido. Estas notificaciones no se tratan. Además, la
fecha actual se archiva como fecha de interrupción en el campo
CompletionDate. Después de la supresión del fallo debe
ponerse el estado de nuevo manualmente en "1". El
CompletionDate y el RetryCount deben posponerse
igualmente.
\vskip1.000000\baselineskip
Es necesario el "arreglo" regular de la
cola de petición de comunicación. Todos los casos realizados, que
están realizados hace más de un intervalo determinado (por ejemplo,
una semana), deberían suprimirse de la base de datos. Además,
deberían suprimirse de la cola de petición de comunicación todos los
casos de fallo que tengan más de un mes. La fecha del acabado o
interrupción se archiva en el campo CompletionDate. A modo
de ejemplo se realiza
así:
así:
Delete from Communication_queue
Where State = 2 and completion_date < now + 7
days
Or state = 9 and completion_date < now + 30
days
\vskip1.000000\baselineskip
Los fallos durante el envío de
e-mails o SMS deberían registrarse en un fichero LOG
de fallos. Estos ficheros LOG deberían supervisarse regularmente
para poder determinar, por ejemplo, la avería de una pasarela.
Además, al menos en una primera fase deberían registrarse
igualmente todas las notificaciones enviadas. Para ello se emplea
un fichero LOG propio para simplificar la supervisión de fallos.
\newpage
Para la realización del temporizador hay varias
alternativas. Puede realizarse
- a través del temporizador interno del servidor
de la aplicación,
- a través de un
cronograma-trabajo
- a través de un temporizador de base de datos
o
- una solución desarrollada de otra manera.
\vskip1.000000\baselineskip
Se prefiere la primera variante. Son posibles
también varias alternativas para la unión del envío de
e-mails y de SMS:
- JMAPI (Java Message API)
- JMS
- Utilización de un servicio de
e-mails apropiado del servidor de la aplicación
\vskip1.000000\baselineskip
Aquí se prefieren las dos primeras
variantes.
Distribución
El componente de notificación no debe comprende
superficies o páginas de internet. Además, para las notificaciones
individuales son necesarias diferentes plantillas. En este caso es
ventajoso si las plantillas pueden intercambiarse fácilmente. Las
plantillas indicadas en los párrafos siguientes representan sólo
ejemplos de realización a modo de ejemplo. Pueden integrarse
naturalmente textos deseados cualesquiera de notificación con
espacios correspondientes.
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\newpage
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\newpage
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
Requerimientos en otros componentes.
\vskip1.000000\baselineskip
Un objeto de paquete debe prepararse, que
suministra información de un paquete identificado por un número de
paquete unívoco:
\bullet El paquete debe preparar un método que
devuelve la fecha de vencimiento en la que el paquete se retira de
la máquina automática de paquetes. Esto se necesita para poder
transmitir notificaciones X días antes del vencimiento. Si no debe
ponerse una fecha de vencimiento puede adoptarse, por ejemplo, de
forma estandarizada un número determinado de días (por ejemplo, 9
días).
\bullet A través de un método debe
suministrarse el objeto de contrato de entrega.
\bullet El objeto de paquete prepara un método
mediante el que puede accederse a la máquina automática en la que
se encuentra el paquete.
\newpage
La máquina de objetos permite acceso a la base
de datos de máquinas automáticas 90, identificada por la ID de la
máquina automática.
\bullet Los métodos en este objeto deben
suministrar información sobre el emplazamiento de una máquina
automática.
\vskip1.000000\baselineskip
El objeto de usuario suministra
información de un cliente, identificado por el número de cliente. El
objeto de proveedor de logística permite acceso a la base de
datos de proveedores de logística. El objeto de contratista de
logística suministra información de un contratista de
logística.
\bullet Todos los objetos implementan un
interface común notificable. Este prepara los métodos
necesarios para el envío de una notificación al objeto
correspondiente, por ejemplo, para la lectura de la dirección de
e-mail o el encabezamiento.
\bullet Debe ser posible identificar un objeto
notificable a través de un ID unívoco. Para ello puede volverse,
por ejemplo, la ID del usuario, objeto de proveedor de logística
o contratista de logística concatenado con una identificación
del tipo de objeto (US_, LP_, LC_) a través de un metido
getUniqueID. Este método debería estar definido
convenientemente en el interface notificable.
\bullet Para reconstruir de nuevo un objeto
notificable identificado a través de esta ID se implementa
una fábrica de objetos que contacta con el objeto correspondiente
mediante una ID semejante.
\vskip1.000000\baselineskip
\bullet La lógica B2B puede consultarse para
todos los objetos, por ejemplo, a través de un interface común.
\bullet Un objeto semejante puede
identificarse a través de una ID unívoca. Para ello puede usarse la
ID del objeto notificable (getUniqueID) que ya existe para
el proveedor de logística y el contratista de
logística. Un método correspondiente debería estar presente
también en el contrato de entrega que devuelve entonces la
ID del objeto concatenada con una identificación del tipo de objeto
(DC_).
\vskip1.000000\baselineskip
\bullet Todos los e-mails se
envían offline inscribiéndose en una cola de comunicación de la que
se leen y procesan a intervalos regulares.
\bullet La implementación puede apoyar el
fomento de cualquier idioma (pero preferiblemente fijado).
\bullet Los e-mails se
transmiten preferiblemente como texto sin formato.
\vskip1.000000\baselineskip
\bullet Fomento de e-mails con
formato HTML.
\bullet En este caso el cliente puede elegir
durante el registro en que formato quiere recibir los
e-mails (texto sin formato o HTML). Al enviarse se
ponen correspondientemente otras plantillas.
\bullet Multilingüe
El cliente puede elegir su idioma preferido
durante el registro. Al enviarse se ponen correspondientemente
otras plantillas.
\bullet Fomento de notificaciones con el
estándar RFC1149.
\bullet Además, un sistema de gestión de
contenidos (Content Management System) puede emplearse para poder
organizar fácilmente las plantillas para e-mails y
SMS.
\newpage
- 10
- Interface externo
- 20
- Lógica de contrato de entrega (Delivery Contract Logic)
- 30
- Componente de envío central
- 40
- Cola de petición de comunicación (Communication-Request-Queue)
- 41
- Temporizador
- 50
- Lector de cola (Queue Reader)
- 70
- Base de datos de clientes
- 80
- Base de datos de paquetes
- 90
- Base de datos de máquinas automáticas
- 100
- Base de datos de modelos
- 110
- Plantillas (Templates)
- 120
- Pasarela
Claims (3)
1. Sistema logístico con uno o varios sistemas
de compartimentos para paquetes y con uno o varios usuarios
registrados, comprendiendo el sistema logístico módulos con
funciones para la generación de órdenes de notificación, un
componente de envío central (30), una cola de petición de
comunicación (Communication Request Queue) (40), una base de datos
de modelos (100) con plantillas (Templates) (110) para la generación
de notificaciones individuales para el usuario correspondiente, una
base de datos de clientes (70) con información de clientes, una base
de datos de paquetes (80) con información de paquetes, una base de
datos de máquinas automáticas (90) con información de los sistemas
de compartimentos para paquetes y una pasarela (120) para el envío
de las notificaciones, estando equipado el sistema logístico de
forma que diferentes incidencias dentro del sistema logístico llaman
a diferentes módulos con funciones asociadas para generar ordenes
de notificación que se escriben en una cola de petición de
comunicación (Communication Request Queue) (40) para el envío
directo al componente de envío (30) o para el envío retardado
temporalmente, leyendo un lector de cola (Queue Reader) (50) las
órdenes de notificación de una cola de petición de comunicación
(Communication Request Queue) (40) de forma controlada por
temporizador y transmitiéndolas al componente de envío central (30)
que genera las notificaciones correspondientes específicas del
usuario y las envía a través de una pasarela (120) a los usuarios, y
presentando el sistema logístico una lógica de contrato de entrega
(Delivery Contract Logic) (20) que valida el estado de las órdenes
de notificación antes de la transferencia al componente de envío
central (30).
2. Sistema logístico según la reivindicación 1,
caracterizado porque las bases de datos están equipadas de
forma que se realiza la asignación de datos de clientes, datos de
paquetes y datos de sistemas de compartimentos para paquetes a
través de IDs.
3. Sistema logístico según la reivindicación 1 ó
2, caracterizado porque las incidencias dentro del sistema
logístico son al menos las siguientes:
- registro de un nuevo usuario
- cambio de los datos del usuario
- depósito de un nuevo paquete en un sistema de
compartimentos para paquetes
- recogida de un paquete de un sistema de
compartimentos para paquetes
- devolución de un paquete
- designación de un representante para la
recogida de un paquete
- supresión de un representante.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| DE10238340 | 2002-08-16 | ||
| DE10238340 | 2002-08-16 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2316855T3 true ES2316855T3 (es) | 2009-04-16 |
Family
ID=31895570
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES03792130T Expired - Lifetime ES2316855T3 (es) | 2002-08-16 | 2003-08-06 | Procedimiento y sistema para la transmision de notificaciones a los usuarios de un siustema logistico. |
Country Status (20)
| Country | Link |
|---|---|
| US (1) | US20060085273A1 (es) |
| EP (1) | EP1530771B1 (es) |
| JP (1) | JP2005539294A (es) |
| KR (1) | KR20050058326A (es) |
| CN (1) | CN1666214A (es) |
| AT (1) | ATE417331T1 (es) |
| AU (1) | AU2003266105A1 (es) |
| BR (1) | BR0312488A (es) |
| CA (1) | CA2498038C (es) |
| DE (1) | DE50310903D1 (es) |
| DK (1) | DK1530771T3 (es) |
| ES (1) | ES2316855T3 (es) |
| HK (1) | HK1077377A1 (es) |
| IL (1) | IL166909A (es) |
| NO (1) | NO332028B1 (es) |
| PL (1) | PL375397A1 (es) |
| PT (1) | PT1530771E (es) |
| RU (1) | RU2321181C2 (es) |
| WO (1) | WO2004019241A1 (es) |
| ZA (1) | ZA200501326B (es) |
Families Citing this family (31)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20040133446A1 (en) * | 2002-11-01 | 2004-07-08 | United Parcel Service Of America, Inc. | Alternate delivery location methods and systems |
| JP2009500262A (ja) | 2005-06-21 | 2009-01-08 | ユナイテッド パーセル サービス オブ アメリカ インコーポレイテッド | 個人向け配達サービスを提供するシステムおよび方法 |
| US7765131B2 (en) * | 2006-06-20 | 2010-07-27 | United Parcel Service Of America, Inc. | Systems and methods for providing personalized delivery services |
| AU2008201669B1 (en) * | 2008-04-15 | 2008-07-24 | Encore Business Integrated Solutions Pty Limited | Acknowledgement Delivery System |
| JP4937968B2 (ja) * | 2008-06-19 | 2012-05-23 | 富士通テレコムネットワークス株式会社 | 通信制御装置およびメッセージ生成方法 |
| DE102010004751B4 (de) * | 2010-01-14 | 2014-10-23 | Deutsche Telekom Ag | Verfahren zur Kommunikation zwischen einem Beförderer einer Postsendung und deren Adressaten |
| EP2381396A1 (en) | 2010-04-20 | 2011-10-26 | Deutsche Post AG | Delivery system for objects |
| US20120178480A1 (en) * | 2010-09-03 | 2012-07-12 | Sabse Technologies, Inc. | Messaging systems and methods |
| US20120303540A1 (en) * | 2011-05-25 | 2012-11-29 | United Parcel Service Of America, Inc. | Customer controlled management of shipments |
| US20120303539A1 (en) * | 2011-05-25 | 2012-11-29 | United Parcel Service Of America, Inc. | Customer controlled management of shipments |
| US20120303542A1 (en) * | 2011-05-25 | 2012-11-29 | United Parcel Service Of America, Inc. | Customer controlled management of shipments |
| US20120303541A1 (en) * | 2011-05-25 | 2012-11-29 | United Parcel Service Of America, Inc. | Customer controlled management of shipments |
| US20120303538A1 (en) * | 2011-05-25 | 2012-11-29 | United Parcel Service Of America, Inc. | Customer controlled management of shipments |
| US9916557B1 (en) | 2012-12-07 | 2018-03-13 | United Parcel Service Of America, Inc. | Systems and methods for item delivery and pick-up using social networks |
| US10387824B2 (en) | 2012-12-21 | 2019-08-20 | United Parcel Service Of America, Inc. | Systems and methods for delivery of an item |
| US11144872B2 (en) | 2012-12-21 | 2021-10-12 | United Parcel Service Of America, Inc. | Delivery to an unattended location |
| CN103067893A (zh) * | 2012-12-25 | 2013-04-24 | 孙中杰 | 快递短信自动通知系统及其操作方法 |
| CA2900041C (en) | 2013-02-01 | 2020-04-21 | United Parcel Service Of America, Inc. | Systems and methods for parcel delivery to alternate delivery locations |
| US10521761B2 (en) | 2013-03-12 | 2019-12-31 | United Parcel Service Of America, Inc. | Systems and methods of delivering parcels using attended delivery/pickup locations |
| US20150066795A1 (en) | 2013-08-30 | 2015-03-05 | United Parcel Service Of America, Inc. | Systems, methods, and computer program products for providing a customized content exchange platform between two or more parties |
| US20150100514A1 (en) | 2013-10-09 | 2015-04-09 | United Parcel Service Of America, Inc. | Customer Controlled Management of Shipments |
| EP3058488A4 (en) | 2013-10-14 | 2017-03-15 | United Parcel Service Of America, Inc. | Systems and methods for confirming an identity of an indivdiual, for example, at a locker bank |
| US10002340B2 (en) | 2013-11-20 | 2018-06-19 | United Parcel Service Of America, Inc. | Concepts for electronic door hangers |
| CN114358693B (zh) | 2014-02-16 | 2023-01-10 | 美国联合包裹服务公司 | 基于收货人的时间安排或者位置确定交付位置和时间 |
| US10733563B2 (en) | 2014-03-13 | 2020-08-04 | United Parcel Service Of America, Inc. | Determining alternative delivery destinations |
| CN104299120A (zh) * | 2014-09-23 | 2015-01-21 | 王奕夏 | 一种基于移动终端的快递物品存储远程开箱系统及方法 |
| WO2016077807A2 (en) | 2014-11-14 | 2016-05-19 | United Parcel Service Of America, Inc. | Systems and methods for facilitating shipping of parcels for returning items |
| US10410164B2 (en) | 2014-11-14 | 2019-09-10 | United Parcel Service Of America, Inc | Systems and methods for facilitating shipping of parcels |
| CN104636902A (zh) * | 2015-02-13 | 2015-05-20 | 深圳支付界科技有限公司 | 一种收货信息即时发送的方法及系统 |
| US10600022B2 (en) | 2016-08-31 | 2020-03-24 | United Parcel Service Of America, Inc. | Systems and methods for synchronizing delivery of related parcels via a computerized locker bank |
| US10552271B2 (en) * | 2017-07-31 | 2020-02-04 | International Business Machines Corporation | Switching servers without interrupting a client command-response queue |
Family Cites Families (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US80030A (en) * | 1868-07-14 | William r | ||
| US5278984A (en) * | 1990-12-19 | 1994-01-11 | Bull Hn Information Systems Inc. | Method for managing requests by specifying time intervals for transmitting a minimum number of messages for specific destinations and priority levels |
| US6047264A (en) * | 1996-08-08 | 2000-04-04 | Onsale, Inc. | Method for supplying automatic status updates using electronic mail |
| US6333973B1 (en) * | 1997-04-23 | 2001-12-25 | Nortel Networks Limited | Integrated message center |
| GB2332540B (en) * | 1997-12-18 | 2002-12-04 | Ibm | An improved parcel trace system |
| US6424841B1 (en) * | 1999-02-18 | 2002-07-23 | Openwave Systems Inc. | Short message service with improved utilization of available bandwidth |
| US7081595B1 (en) * | 1999-08-31 | 2006-07-25 | United States Postal Service | Apparatus and methods for processing mailpiece information in a mail processing device using sorter application software |
| US6977353B1 (en) * | 1999-08-31 | 2005-12-20 | United States Postal Service | Apparatus and methods for identifying and processing mail using an identification code |
| US7158941B1 (en) * | 1999-12-03 | 2007-01-02 | Thompson Clifford C | Residential and business logistics system and method |
| US6748295B2 (en) * | 2000-07-26 | 2004-06-08 | Northrop Grumman Corporation | Item delivery and retrieval system |
| US7130803B1 (en) * | 2000-10-13 | 2006-10-31 | Couch John P | Unique virtual dynamically-capable addressing system and method of mail and parcel delivery and forwarding |
| AUPR224400A0 (en) * | 2000-12-21 | 2001-01-25 | Jab Creative.Com Pty Ltd | Electronic document distribution system |
| US6974928B2 (en) * | 2001-03-16 | 2005-12-13 | Breakthrough Logistics Corporation | Method and apparatus for efficient package delivery and storage |
-
2003
- 2003-08-06 US US10/524,063 patent/US20060085273A1/en not_active Abandoned
- 2003-08-06 PT PT03792130T patent/PT1530771E/pt unknown
- 2003-08-06 KR KR1020057002638A patent/KR20050058326A/ko not_active Application Discontinuation
- 2003-08-06 DK DK03792130T patent/DK1530771T3/da active
- 2003-08-06 CN CN038160315A patent/CN1666214A/zh active Pending
- 2003-08-06 PL PL03375397A patent/PL375397A1/xx not_active Application Discontinuation
- 2003-08-06 DE DE50310903T patent/DE50310903D1/de not_active Expired - Lifetime
- 2003-08-06 EP EP03792130A patent/EP1530771B1/de not_active Expired - Lifetime
- 2003-08-06 AT AT03792130T patent/ATE417331T1/de active
- 2003-08-06 WO PCT/DE2003/002647 patent/WO2004019241A1/de active Application Filing
- 2003-08-06 BR BR0312488-6A patent/BR0312488A/pt not_active IP Right Cessation
- 2003-08-06 ES ES03792130T patent/ES2316855T3/es not_active Expired - Lifetime
- 2003-08-06 JP JP2004529711A patent/JP2005539294A/ja active Pending
- 2003-08-06 CA CA2498038A patent/CA2498038C/en not_active Expired - Lifetime
- 2003-08-06 RU RU2005101750/09A patent/RU2321181C2/ru not_active IP Right Cessation
- 2003-08-06 AU AU2003266105A patent/AU2003266105A1/en not_active Abandoned
-
2005
- 2005-01-21 NO NO20050332A patent/NO332028B1/no not_active IP Right Cessation
- 2005-02-15 ZA ZA200501326A patent/ZA200501326B/xx unknown
- 2005-02-15 IL IL166909A patent/IL166909A/en active IP Right Grant
- 2005-10-20 HK HK05109280.5A patent/HK1077377A1/xx not_active IP Right Cessation
Also Published As
| Publication number | Publication date |
|---|---|
| EP1530771B1 (de) | 2008-12-10 |
| ATE417331T1 (de) | 2008-12-15 |
| EP1530771A1 (de) | 2005-05-18 |
| RU2005101750A (ru) | 2005-10-10 |
| US20060085273A1 (en) | 2006-04-20 |
| CA2498038C (en) | 2016-07-05 |
| CN1666214A (zh) | 2005-09-07 |
| NO332028B1 (no) | 2012-05-29 |
| AU2003266105A1 (en) | 2004-03-11 |
| JP2005539294A (ja) | 2005-12-22 |
| KR20050058326A (ko) | 2005-06-16 |
| DE50310903D1 (de) | 2009-01-22 |
| NO20050332L (no) | 2005-01-21 |
| PT1530771E (pt) | 2009-02-16 |
| CA2498038A1 (en) | 2004-03-04 |
| HK1077377A1 (en) | 2006-02-10 |
| DK1530771T3 (da) | 2009-03-16 |
| WO2004019241A1 (de) | 2004-03-04 |
| PL375397A1 (en) | 2005-11-28 |
| RU2321181C2 (ru) | 2008-03-27 |
| BR0312488A (pt) | 2005-05-03 |
| ZA200501326B (en) | 2007-04-25 |
| IL166909A (en) | 2010-06-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2316855T3 (es) | Procedimiento y sistema para la transmision de notificaciones a los usuarios de un siustema logistico. | |
| US10373098B2 (en) | Flexible mail delivery system and method | |
| ZA200501329B (en) | Method and system for data transmission between a package mailbox and at least one central data processing unit in a logistic system | |
| WO2001065444A1 (en) | System and method for shipping, accounting, and tracking common carrier shipments | |
| ES2369493T3 (es) | Procedimiento y dispositivo para la transmisión de notificaciones. | |
| US20040030722A1 (en) | Remote mailbox management system and method | |
| JP2018005696A (ja) | 備蓄品管理システム、備蓄品管理方法及びプログラム | |
| US20020116240A1 (en) | Network server for servicing articles of wear | |
| KR20090035183A (ko) | 우편시스템 | |
| CA2715193A1 (en) | Method for operating a shipping process within a logistics system | |
| KR20030038490A (ko) | 네트워크 이용 운송 서비스 및 네트워크 이용 운송 시스템 | |
| ES2301499T3 (es) | Metodo y sistema para mejorar una transacion comercial dirigida a traves de una red de comunicaciones. | |
| JP2011180886A (ja) | 配達支援システム、方法、およびプログラム | |
| NZ536336A (en) | Method and system for transmitting notifications to users of a logistic system | |
| TWM638454U (zh) | 可快速寄件之物流郵箱系統 | |
| EP3751483A1 (en) | System and method for mailing a packaging unit | |
| ES2396393B1 (es) | Procedimiento para la verificación de la transmisión y recepción de mensajes en sistemas de comunicación telemáticos | |
| KR20040082768A (ko) | 전자인증 서비스 장치 및 방법 | |
| EP2916274A1 (en) | Method of integrating postal service | |
| KR20000058840A (ko) | 인터넷을 이용한 배송시스템 | |
| JP2001325332A (ja) | 配送システム及び配送方法 | |
| WO2008097070A1 (en) | A method to give effect to a predetermined function | |
| JP2002259470A (ja) | 図面配布管理装置 | |
| JP2002092113A (ja) | 宅配便における配達物品の一時預かりシステム |