First draft of processes
This commit is contained in:
Xavier Bustamante Talavera
parent
33f6ee540b
commit
dd5ca4e513
|
|
@ -42,14 +42,22 @@ The following actions describe and react on the
|
||||||
:class:`ereuse_devicehub.resources.device.states.Physical` condition
|
:class:`ereuse_devicehub.resources.device.states.Physical` condition
|
||||||
of the devices.
|
of the devices.
|
||||||
|
|
||||||
ToPrepare, Prepare
|
ToPrepare and Prepare
|
||||||
==================
|
==================
|
||||||
|
Prepare
|
||||||
|
-------
|
||||||
.. autoclass:: ereuse_devicehub.resources.event.models.Prepare
|
.. autoclass:: ereuse_devicehub.resources.event.models.Prepare
|
||||||
|
ToPrepare
|
||||||
|
---------
|
||||||
.. autoclass:: ereuse_devicehub.resources.event.models.ToPrepare
|
.. autoclass:: ereuse_devicehub.resources.event.models.ToPrepare
|
||||||
|
|
||||||
ToRepair, Repair
|
ToRepair, Repair
|
||||||
================
|
================
|
||||||
|
Repair
|
||||||
|
------
|
||||||
.. autoclass:: ereuse_devicehub.resources.event.models.Repair
|
.. autoclass:: ereuse_devicehub.resources.event.models.Repair
|
||||||
|
ToRepair
|
||||||
|
--------
|
||||||
.. autoclass:: ereuse_devicehub.resources.event.models.ToRepair
|
.. autoclass:: ereuse_devicehub.resources.event.models.ToRepair
|
||||||
|
|
||||||
ReadyToUse
|
ReadyToUse
|
||||||
|
|
@ -83,9 +91,11 @@ and **organize** actions.
|
||||||
|
|
||||||
.. uml:: association-events.puml
|
.. uml:: association-events.puml
|
||||||
|
|
||||||
Trade actions
|
Trade
|
||||||
=============
|
=====
|
||||||
Not fully developed.
|
|
||||||
|
.. todo Not fully developed.
|
||||||
|
|
||||||
.. autoclass:: ereuse_devicehub.resources.event.models.Trade
|
.. autoclass:: ereuse_devicehub.resources.event.models.Trade
|
||||||
|
|
||||||
Sell
|
Sell
|
||||||
|
|
|
||||||
|
|
@ -38,10 +38,10 @@ For generic devices, the process is as follows:
|
||||||
:ref:`tags:eTags`, manufacturer tags (like serial numbers), and
|
:ref:`tags:eTags`, manufacturer tags (like serial numbers), and
|
||||||
tags provided by third-parties like donors.
|
tags provided by third-parties like donors.
|
||||||
3. The user manually introduces other information, like ratings,
|
3. The user manually introduces other information, like ratings,
|
||||||
and submits the information to Devicehub.
|
finally submitting the information to Devicehub.
|
||||||
|
|
||||||
For a computer, `This video <https://vimeo.com/250253019>`_ explains
|
For a computer, `This video <https://vimeo.com/250253019>`_ explains
|
||||||
the process using generic tags, and it is as follows:
|
the process, and it is as follows:
|
||||||
|
|
||||||
1. The user connects the computers to process to an eReuse.org Box
|
1. The user connects the computers to process to an eReuse.org Box
|
||||||
running the Workbench Server software using a local network.
|
running the Workbench Server software using a local network.
|
||||||
|
|
@ -59,38 +59,40 @@ the process using generic tags, and it is as follows:
|
||||||
5. Android App and Workbench embed the information into a report
|
5. Android App and Workbench embed the information into a report
|
||||||
that is submitted to Devicehub.
|
that is submitted to Devicehub.
|
||||||
|
|
||||||
|
.. _prepare:
|
||||||
|
|
||||||
Preparing a device for use
|
Preparing a device for use
|
||||||
==========================
|
==========================
|
||||||
Users, like refurbishers, ready the devices so they are suitable
|
Users, like refurbishers, ready the devices so they are suitable
|
||||||
for trading. This process implies repairing, cleaning...
|
for trading. This process implies repairing, cleaning, etc.
|
||||||
|
|
||||||
1. The user scans the tag of the device with the Android App or searches it from the
|
1. The user scans the tag of the device with the Android App or searches it from the
|
||||||
website and selects *actions* > *:ref:`actions:ToPrepare, Prepare <ToPrepare>`*,
|
website and selects *actions* > :ref:`actions:ToPrepare`,
|
||||||
which informs Devicehub that a device has to be prepared for trading.
|
which informs Devicehub that a device has to be prepared for trading.
|
||||||
2. The user prepares the device. Upon success, it performs the action
|
2. The user prepares the device. Upon success, it performs the action
|
||||||
:ref:`actions:ToPrepare, Prepare <Prepare>` in the similar way that
|
:ref:`actions:Prepare` in the similar way that
|
||||||
did in 1.
|
did in 1.
|
||||||
3. A prepared device might still not be ready for trading. For example,
|
3. A prepared device might still not be ready for trading. For example,
|
||||||
a seller still might want to clean a device once a trade has been
|
a seller still might want to clean a device once a trade has been
|
||||||
confirmed, as the device would have gathered dust between the
|
confirmed, for example because the device gathered dust between
|
||||||
preparation and the trading. To denote a final "this device is
|
the preparation and trading. To denote a final "this device is
|
||||||
ready to be shipped to a customer state", the user performs
|
ready to be used or shipped", the user performs
|
||||||
the action :ref:`actions:ReadyToUse` in the same way it did in 1.
|
the action :ref:`actions:ReadyToUse` in the same way it did in 1.
|
||||||
|
|
||||||
If the device is broken or breaks, the user performs the action
|
If the device is broken or it breaks, the user performs the action
|
||||||
:ref:`actions:ToRepair` denoting that the device has to be repaired,
|
:ref:`actions:ToRepair` denoting that the device has to be repaired,
|
||||||
and :ref:`actions:Repair` upon success.
|
and :ref:`actions:Repair` upon success.
|
||||||
|
|
||||||
Broken devices that are not going to be fixed might be set for
|
Broken devices that are not going to be fixed are set to
|
||||||
:ref:`Dispose a device <disposition>`.
|
`Dispose a device`_.
|
||||||
|
|
||||||
Track a device
|
Track a device
|
||||||
==============
|
==============
|
||||||
:ref:`processing a device with workbench` registers into Devicehub
|
`processing a device with workbench`_ registers into Devicehub
|
||||||
the required metadata from a device to identify it: a digital
|
the required metadata from a device to identify it: a digital
|
||||||
passport for the device (information submitted in a Devicehub),
|
passport for the device (information submitted in a Devicehub),
|
||||||
plus a physical passport (a tag that links the device with the digital
|
plus a physical passport (a tag that links the device with the digital
|
||||||
passport). If the physical passport is an :ref:`tags:eTag` then
|
passport). If the physical passport is an :ref:`tags:eTags` then
|
||||||
it is unforgeable.
|
it is unforgeable.
|
||||||
|
|
||||||
The rest of the traceability is based in keeping track of the events
|
The rest of the traceability is based in keeping track of the events
|
||||||
|
|
@ -99,207 +101,7 @@ it is traded. eReuse.org allows recording these actions, providing
|
||||||
mechanisms to ease them or ensure them. Please refer to the specific
|
mechanisms to ease them or ensure them. Please refer to the specific
|
||||||
use cases for more information.
|
use cases for more information.
|
||||||
|
|
||||||
Checking device authenticity
|
.. _share:
|
||||||
============================
|
|
||||||
Any user can check the authenticity of a device registered in a
|
|
||||||
Devicehub, even if the user is external, like a customer.
|
|
||||||
|
|
||||||
If the device has an :ref:`tags:eTag` or a regular tag generated by
|
|
||||||
a Devicehub (stuck on the :ref:`Processing a device with Workbench`),
|
|
||||||
the process is as follows:
|
|
||||||
|
|
||||||
1. The user scans the QR code with a smartphone using a generic QR
|
|
||||||
codes scanner.
|
|
||||||
2. The scanner opens the browser and takes the user to a webpage
|
|
||||||
containing public information of the device. Part of this
|
|
||||||
information are the serial numbers and other IDs of the device,
|
|
||||||
and a set of instructions in how to challenge the Photochromic
|
|
||||||
tag of the device, if the device has one stuck, to double-check
|
|
||||||
its veracity.
|
|
||||||
3. The user tests the photochromic tag by touching the flash bulb of
|
|
||||||
the smartphone with the tag for, at least, 6 seconds, checking
|
|
||||||
that the tag changes color temporarily.
|
|
||||||
|
|
||||||
Other ways of checking device authenticity are:
|
|
||||||
|
|
||||||
- Scanning the QR code stuck and comparing the serial numbers of the
|
|
||||||
device with the ones of the public webpage.
|
|
||||||
- Directly applying the photochromic challenge.
|
|
||||||
|
|
||||||
Workbench and Devicehub detect changes in computer components. Certain
|
|
||||||
scenarios where the computer passed by untrusted users require
|
|
||||||
ensuring that no component has been taken.
|
|
||||||
A deeper verification process is re-processing the computer with
|
|
||||||
Workbench, generating a new report that updates the information of
|
|
||||||
the computer in the Devicehub, ultimately showing the differences
|
|
||||||
in removed and added components.
|
|
||||||
|
|
||||||
Finally, the eReuse.org team is developing, using the platform Evrythng,
|
|
||||||
a global record of devices, which takes non-private IDs of the devices
|
|
||||||
of participating Devicehubs and records the most important life
|
|
||||||
events of the devices. This database is publicly available, so
|
|
||||||
users can search on it an ID of a device, for example the S/N or the one
|
|
||||||
written in a tag, like an :ref:`tags:eTag`, and know which Devicehub
|
|
||||||
registered in, ultimately accessing the public information of the device.
|
|
||||||
|
|
||||||
Recover a lost device
|
|
||||||
=====================
|
|
||||||
Users can recover a lost device found in a waste dump by following the
|
|
||||||
process of :ref:`checking device authenticity`.
|
|
||||||
|
|
||||||
A Devicehub participating in the global record of devices (explained
|
|
||||||
in :ref:`checking device authenticity`) automatically uploads public
|
|
||||||
device information into Evrythng. If the device was previously
|
|
||||||
registered in another Devicehub and there is no record of trading
|
|
||||||
between Devicehubs, Evrythng warns both systems. Note that this
|
|
||||||
functionality is in development.
|
|
||||||
|
|
||||||
Rating a device
|
|
||||||
===============
|
|
||||||
Rating a device is the act of grading the appearance, performance,
|
|
||||||
and functionality of a device. This results in a :ref:`actions:Rate`
|
|
||||||
action, which includes a guessed **price** for the device.
|
|
||||||
|
|
||||||
There are two ways of rating a device:
|
|
||||||
|
|
||||||
1. When processing a computer with Workbench and the Android App.
|
|
||||||
1. While Workbench is processing the machine, the user
|
|
||||||
links the tag with the computer. In this process, as it requires the
|
|
||||||
user to scan the tag with the App, the app allows the user to introduce
|
|
||||||
more information, including the appearance and functionality.
|
|
||||||
2. The App embeds the rate with the device report generated by the
|
|
||||||
Workbench.
|
|
||||||
3. The Workbench uploads the report to Devicehub.
|
|
||||||
2. Anytime with the Android App or website.
|
|
||||||
- The user scans the tag of the device with the Android App.
|
|
||||||
After scanning it, the App allows the user to rate the
|
|
||||||
appearance and functionality.
|
|
||||||
- Through the website, the user searches the device and then
|
|
||||||
selects to perform a new :ref:`actions:ManualRate`, rating
|
|
||||||
the appearance and functionality.
|
|
||||||
|
|
||||||
In any case, when Devicehub receives the ratings, it computes a final
|
|
||||||
global :ref:`actions:Rate`, embedding a guessed price for the device.
|
|
||||||
|
|
||||||
Refer to :ref:`actions:Rate` for technical details.
|
|
||||||
|
|
||||||
Storing devices
|
|
||||||
===============
|
|
||||||
Devices are stored in places like warehouses.
|
|
||||||
|
|
||||||
:ref:`lots:`, :ref:`actions:Locate`, :ref:`actions:Receive`,
|
|
||||||
and :ref:`actions:Live`, actions help locating devices,
|
|
||||||
from a global scale to inside places.
|
|
||||||
|
|
||||||
The :ref:`actions:Locate`, :ref:`actions:Receive`,
|
|
||||||
and :ref:`actions:Live`; embed approximated city or province level
|
|
||||||
information, and the user can write a location, name, or address
|
|
||||||
in Locate and Receive. This location can be as detailed as required,
|
|
||||||
like shelves in a building. Users can create actions by scanning
|
|
||||||
a tag with the App or searching a device through the website,
|
|
||||||
and then selecting *create an action*.
|
|
||||||
|
|
||||||
Lots are more versatile than actions, and they do not pollute the
|
|
||||||
traceability log, which is unneeded when placing devices in temporal
|
|
||||||
places like warehouses. Lots act like folders in an Operative System,
|
|
||||||
so the user is free to choose what each lot represents —for example
|
|
||||||
physical locations. For example:
|
|
||||||
|
|
||||||
- Lot company ACME
|
|
||||||
|
|
||||||
- Lot Warehouse 1 of ACME
|
|
||||||
|
|
||||||
- Lot Zone A
|
|
||||||
|
|
||||||
- Computer 1
|
|
||||||
- Monitor 2
|
|
||||||
|
|
||||||
To create a lot the user uses the webiste or App, selecting *create lot*
|
|
||||||
and giving it a name.
|
|
||||||
|
|
||||||
To place devices inside a lot through the website, the user selects
|
|
||||||
the devices, it presses *add to lot*, and writes the name of the lot.
|
|
||||||
To place them through the App, the user scans the tags of the devices,
|
|
||||||
it presses *add to lot*, and writes the name of the lot.
|
|
||||||
|
|
||||||
To look for devices the user reduces the area to look for them by
|
|
||||||
checking to which lot the device is. This is done through the website
|
|
||||||
or App by searching the device and checking to which lots is inside,
|
|
||||||
or searching the lot and checking which devices are inside. And then,
|
|
||||||
the user visually checks the identifier printed in the tags of devices
|
|
||||||
that are in that specific place until finding the one.
|
|
||||||
|
|
||||||
Erasing data and obtaining a certificate
|
|
||||||
========================================
|
|
||||||
|
|
||||||
.. todo add a reference that explains how Workbench works in general
|
|
||||||
|
|
||||||
Workbench erases data storage units, once the user configured Workbench
|
|
||||||
to do so. In the configuration users parametrize the erasure to
|
|
||||||
follow their desired erasure standard (which involves selecting
|
|
||||||
erasure steps, data written or verification, for example).
|
|
||||||
|
|
||||||
Once the Workbench uploads the report to a Devicehub, users can get
|
|
||||||
the erasure certificate of the (data storage units of the) computer.
|
|
||||||
|
|
||||||
An external user, like a client, if scans the tag with a smartphone,
|
|
||||||
can see an on-line version of the certificate with its smartphone
|
|
||||||
web browser.
|
|
||||||
|
|
||||||
A logged-in user with access to the device, can scan the tag with
|
|
||||||
the App or search the device through the web app and select
|
|
||||||
*certificates*, then *erasure certificate*, to view an on-line
|
|
||||||
version of the certificate and download a PDF.
|
|
||||||
|
|
||||||
Please refer to :ref:`actions:Erase` for detailed information about
|
|
||||||
how erasures work and which information they take.
|
|
||||||
|
|
||||||
Delivery
|
|
||||||
========
|
|
||||||
:ref:`actions:Receive` is the act of physically taking delivery of a
|
|
||||||
device. When an user performs a Receive, it means that another user took
|
|
||||||
the device physically, confirming reception.
|
|
||||||
|
|
||||||
To perform this action the user scans the tag of the devices with the App,
|
|
||||||
or search it through the website, and selects *actions* > *Receive*,
|
|
||||||
filling information about the receiver and delivery.
|
|
||||||
|
|
||||||
An exemplifying case is delivering a device from the warehouse to
|
|
||||||
a customer through a transporter:
|
|
||||||
|
|
||||||
1. Warehouse employees look in the website devices that are
|
|
||||||
:ref:`actions:Trade` (sold, donated, rented) that are still in
|
|
||||||
the warehouse and ready to be used.
|
|
||||||
2. They look for them in the warehouse. Refer to :ref:`Storing devices`
|
|
||||||
for more details.
|
|
||||||
3. Once the devices are located the employees give them to the
|
|
||||||
transporter. To acknowledge this to the system, they scan the
|
|
||||||
tags of those devices with the App and perform the action
|
|
||||||
:ref:`actions:Receive`, stating that the transporter received the
|
|
||||||
devices.
|
|
||||||
4. The transporter takes the devices to the customer, performing the
|
|
||||||
same :ref:`actions:Receive` again, this time stating that the
|
|
||||||
customer received the devices.
|
|
||||||
|
|
||||||
Value (price) devices
|
|
||||||
=====================
|
|
||||||
Devicehub guesses automatically a price after each new rate, explained
|
|
||||||
in :ref:`Rating a device`, and manually by performing the action
|
|
||||||
:ref:`actions:Price`. By doing manually it, the user can set any
|
|
||||||
price.
|
|
||||||
|
|
||||||
To perform a manual price the user scans the tags of the devices
|
|
||||||
with the App, or searches them through the website, and selects
|
|
||||||
*actions* > *price*.
|
|
||||||
|
|
||||||
The user has still a chance to set the final trading price when
|
|
||||||
performing :ref:`actions:Trade`. If the user does not set any price,
|
|
||||||
and the trade is not a :ref:`actions:Donation` or similar, Devicehub
|
|
||||||
assumes that the last known price is the one which the device is
|
|
||||||
sold.
|
|
||||||
|
|
||||||
Refer to :ref:`actions:Price` to know the technical details in how
|
|
||||||
Devicehub guesses the price.
|
|
||||||
|
|
||||||
Share device information
|
Share device information
|
||||||
========================
|
========================
|
||||||
|
|
@ -329,13 +131,233 @@ scans the QR of the tag through its smartphone, as the QR contains
|
||||||
a public link of the device. This way people in physical contact with the
|
a public link of the device. This way people in physical contact with the
|
||||||
device, like consumers, can always check information about the device.
|
device, like consumers, can always check information about the device.
|
||||||
|
|
||||||
|
|
||||||
|
.. _public-webpage:
|
||||||
|
|
||||||
|
The public webpage
|
||||||
|
------------------
|
||||||
|
The public webpage of a device includes:
|
||||||
|
|
||||||
|
- A description of the device, including specifications,
|
||||||
|
public identifiers, and associated tags.
|
||||||
|
- Instructions in how to challenge the Photochromic tag of the
|
||||||
|
device for `checking device authenticity`_.
|
||||||
|
- Traceability log of the device.
|
||||||
|
- :ref:`The public custody chain for present devices <public-custody>`.
|
||||||
|
- Certificates like erasures.
|
||||||
|
|
||||||
|
Checking device authenticity
|
||||||
|
============================
|
||||||
|
Any user can check the authenticity of a device registered in a
|
||||||
|
Devicehub, even if the user is not registered, like a customer.
|
||||||
|
|
||||||
|
If the device has an :ref:`tags:eTags` or a regular tag generated by
|
||||||
|
a Devicehub (stuck on the `Processing a device with Workbench`_),
|
||||||
|
the process is as follows:
|
||||||
|
|
||||||
|
1. The user scans the QR code with a smartphone using a generic QR
|
||||||
|
code scanner.
|
||||||
|
2. The scanner opens the browser and takes the user to
|
||||||
|
`the public webpage`_ containing public information of the
|
||||||
|
device, like identifiers and instructions in how to challenge the
|
||||||
|
photochromic tag.
|
||||||
|
3. The user tests the photochromic tag by touching the flash bulb of
|
||||||
|
the smartphone with the tag for, at least, 6 seconds, checking
|
||||||
|
that the tag changes color temporarily.
|
||||||
|
|
||||||
|
Other ways of checking device authenticity are:
|
||||||
|
|
||||||
|
- Scanning the QR code stuck and comparing the serial numbers of the
|
||||||
|
device with the ones of the public webpage.
|
||||||
|
- Directly applying the photochromic challenge.
|
||||||
|
|
||||||
|
Workbench and Devicehub detect changes in computer components. Certain
|
||||||
|
scenarios where the computer passed by untrusted users require
|
||||||
|
ensuring that no component has been taken or replaced.
|
||||||
|
A deeper verification process is re-processing the computer with
|
||||||
|
Workbench, generating a new report that updates the information of
|
||||||
|
the computer in the Devicehub, ultimately showing the differences
|
||||||
|
in removed and added components.
|
||||||
|
|
||||||
|
Finally, the eReuse.org team is developing, using the platform Evrythng,
|
||||||
|
a global record of devices, which takes non-private IDs of the devices
|
||||||
|
of participating Devicehubs and records the most important life
|
||||||
|
events of the devices. This database is publicly available, so
|
||||||
|
users can search on it an ID of a device, for example the S/N or the one
|
||||||
|
written in a tag, like an :ref:`tags:eTags`, and know which Devicehub is
|
||||||
|
registered in, ultimately accessing the public information of the device.
|
||||||
|
|
||||||
|
Recover a lost device
|
||||||
|
=====================
|
||||||
|
Users can recover a lost device found in a waste dump by following the
|
||||||
|
process of `checking device authenticity`_.
|
||||||
|
|
||||||
|
A Devicehub participating in the global record of devices (explained
|
||||||
|
in `checking device authenticity`_) automatically uploads public
|
||||||
|
device information into Evrythng. If the device was previously
|
||||||
|
registered in another Devicehub and there is no record of trading
|
||||||
|
between Devicehubs, Evrythng warns both systems. Note that this
|
||||||
|
functionality is in development.
|
||||||
|
|
||||||
|
Rating a device
|
||||||
|
===============
|
||||||
|
Rating a device is the act of grading the appearance, performance,
|
||||||
|
and functionality of a device. This results in a :ref:`actions:Rate`
|
||||||
|
action, which includes a guessed **price** for the device.
|
||||||
|
|
||||||
|
There are two ways of rating a device:
|
||||||
|
|
||||||
|
1. When processing a computer with Workbench and the Android App.
|
||||||
|
|
||||||
|
1. While Workbench is processing the machine, the user
|
||||||
|
links the tag with the computer. In this process, as it requires the
|
||||||
|
user to scan the tag with the App, the app allows the user to introduce
|
||||||
|
more information, including the appearance and functionality.
|
||||||
|
2. The App embeds the rate with the device report generated by the
|
||||||
|
Workbench.
|
||||||
|
3. The Workbench uploads the report to Devicehub.
|
||||||
|
2. Anytime with the Android App or website.
|
||||||
|
|
||||||
|
- The user scans the tag of the device with the Android App.
|
||||||
|
After scanning it, the App allows the user to rate the
|
||||||
|
appearance and functionality.
|
||||||
|
- Through the website, the user searches the device and then
|
||||||
|
selects to perform a new :ref:`actions:ManualRate`, rating
|
||||||
|
the appearance and functionality.
|
||||||
|
|
||||||
|
In any case, when Devicehub receives the ratings, it computes a final
|
||||||
|
global :ref:`actions:Rate`, embedding a guessed price for the device.
|
||||||
|
|
||||||
|
Refer to :ref:`actions:Rate` for technical details.
|
||||||
|
|
||||||
|
.. _storing:
|
||||||
|
|
||||||
|
Storing devices
|
||||||
|
===============
|
||||||
|
Devices are stored in places like warehouses.
|
||||||
|
|
||||||
|
:ref:`lots:`, :ref:`actions:Locate`, :ref:`actions:Receive`,
|
||||||
|
and :ref:`actions:Live`, actions help locating devices,
|
||||||
|
from a global scale to inside places.
|
||||||
|
|
||||||
|
The :ref:`actions:Locate`, :ref:`actions:Receive`,
|
||||||
|
and :ref:`actions:Live` embed approximated city or province level
|
||||||
|
information, and the user can write a location, name, or address
|
||||||
|
in Locate and Receive. This location can be as detailed as required,
|
||||||
|
like shelves in a building. Users can create actions by scanning
|
||||||
|
a tag with the App or searching a device through the website,
|
||||||
|
and then selecting *create an action*.
|
||||||
|
|
||||||
|
Lots are more versatile than actions, and they do not pollute the
|
||||||
|
traceability log, which is unneeded when placing devices in temporal
|
||||||
|
places like warehouses. Lots act like folders in an Operative System,
|
||||||
|
so the user is free to choose what each lot represents —for example
|
||||||
|
physical locations:
|
||||||
|
|
||||||
|
- Lot company ACME
|
||||||
|
|
||||||
|
- Lot Warehouse 1 of ACME
|
||||||
|
|
||||||
|
- Lot Zone A
|
||||||
|
|
||||||
|
- Computer 1
|
||||||
|
- Monitor 2
|
||||||
|
|
||||||
|
To create a lot the user uses the webiste or App, selecting *create lot*
|
||||||
|
and giving it a name.
|
||||||
|
|
||||||
|
To place devices inside a lot through the website, the user selects
|
||||||
|
the devices, it presses *add to lot*, and writes the name of the lot.
|
||||||
|
To place them through the App, the user scans the tags of the devices,
|
||||||
|
it presses *add to lot*, and writes the name of the lot.
|
||||||
|
|
||||||
|
To look for devices the user reduces the area to look for them by
|
||||||
|
checking to which lot the device is. This is done through the website
|
||||||
|
or App by searching the device and checking to which lots is inside,
|
||||||
|
or searching the lot and checking which devices are inside. Once the
|
||||||
|
user is in the place, it picks up the correct device by reading
|
||||||
|
its tag.
|
||||||
|
|
||||||
|
Erasing data and obtaining a certificate
|
||||||
|
========================================
|
||||||
|
|
||||||
|
When `Processing a device with Workbench`_ user can order Workbench
|
||||||
|
to erase the data stroage units. In the configuration users parametrize
|
||||||
|
the erasure to follow their desired erasure standard (involving
|
||||||
|
customizing erasure steps).
|
||||||
|
|
||||||
|
Once the Workbench uploads the report to a Devicehub, the user gets
|
||||||
|
the erasure certificate of the (data storage units of the) computer.
|
||||||
|
|
||||||
|
A logged-in user with access to the device can scan the tag with
|
||||||
|
the App or search the device through the web app and select
|
||||||
|
*certificates*, then *erasure certificate*, to view an on-line
|
||||||
|
version of the certificate and download a PDF.
|
||||||
|
|
||||||
|
An external user can access `The public webpage`_ of the device
|
||||||
|
to download the erasure certificate.
|
||||||
|
|
||||||
|
Please refer to :ref:`actions:Erase` for detailed information about
|
||||||
|
how erasures work and which information they take.
|
||||||
|
|
||||||
|
.. _delivery:
|
||||||
|
|
||||||
|
Delivery
|
||||||
|
========
|
||||||
|
:ref:`actions:Receive` is the act of physically taking delivery of a
|
||||||
|
device. When an user performs a Receive, it means that another user took
|
||||||
|
the device physically, confirming reception.
|
||||||
|
|
||||||
|
To perform this action the user scans the tag of the devices with the App,
|
||||||
|
or search it through the website, and selects *actions* > *Receive*,
|
||||||
|
filling information about the receiver and delivery.
|
||||||
|
|
||||||
|
An exemplifying case is delivering a device from the warehouse to
|
||||||
|
a customer through a transporter:
|
||||||
|
|
||||||
|
1. Warehouse employees look in the website devices that are sold,
|
||||||
|
donated, rented (:ref:`actions:Trade`) that are still in
|
||||||
|
the warehouse and ready to be used.
|
||||||
|
2. They :ref:`store devices <storing>` in the warehouse.
|
||||||
|
3. Once the devices are located the employees give them to the
|
||||||
|
transporter. To acknowledge this to the system, they scan the
|
||||||
|
tags of those devices with the App and perform the action
|
||||||
|
:ref:`actions:Receive`, stating that the transporter received the
|
||||||
|
devices.
|
||||||
|
4. The transporter takes the devices to the customer, performing the
|
||||||
|
same :ref:`actions:Receive` again, this time stating that the
|
||||||
|
customer received the devices.
|
||||||
|
|
||||||
|
The last :ref:`actions:Receive` of a delivery, the one referring
|
||||||
|
to the final customer, can :ref:`activate the warranty <warranty>`.
|
||||||
|
|
||||||
|
Value (price) devices
|
||||||
|
=====================
|
||||||
|
Devicehub guesses automatically a price after each new rate, explained
|
||||||
|
in `Rating a device`_, and manually by performing the action
|
||||||
|
:ref:`actions:Price`. By doing manually it, the user can set any
|
||||||
|
price.
|
||||||
|
|
||||||
|
To perform a manual price the user scans the tags of the devices
|
||||||
|
with the App, or searches them through the website, and selects
|
||||||
|
*actions* > *price*.
|
||||||
|
|
||||||
|
The user has still a chance to set the final trading price when
|
||||||
|
performing :ref:`actions:Trade`. If the user does not set any price,
|
||||||
|
and the trade is not a :ref:`actions:Donation` or similar, Devicehub
|
||||||
|
assumes that the last known price is the one which the device is
|
||||||
|
sold.
|
||||||
|
|
||||||
|
Refer to :ref:`actions:Price` to know the technical details in how
|
||||||
|
Devicehub guesses the price.
|
||||||
|
|
||||||
Manage sale with buyer (reserve, outgoing lots, sell, receive)
|
Manage sale with buyer (reserve, outgoing lots, sell, receive)
|
||||||
==============================================================
|
==============================================================
|
||||||
We exemplify the use of lots and actions to manage sales with
|
We exemplify the use of lots and actions to manage sales with
|
||||||
a buyer.
|
a buyer.
|
||||||
|
|
||||||
1. The first step on sales is for a seller to showcase the devices
|
1. The first step on sales is for a seller to showcase the devices
|
||||||
to potential customers by :ref:`sharing them <share device information>`.
|
to potential customers by :ref:`sharing them <share>`.
|
||||||
2. A customer inquires about the devices, for example through e-mail.
|
2. A customer inquires about the devices, for example through e-mail.
|
||||||
3. This can imply a reservation process.
|
3. This can imply a reservation process.
|
||||||
In such case, the seller can perform the action :ref:`actions:Reserve`,
|
In such case, the seller can perform the action :ref:`actions:Reserve`,
|
||||||
|
|
@ -343,24 +365,22 @@ a buyer.
|
||||||
To perform that action, the user scan the tags of the devices
|
To perform that action, the user scan the tags of the devices
|
||||||
with the App or search them through the website, select them,
|
with the App or search them through the website, select them,
|
||||||
and click *actions* > *Reserve*.
|
and click *actions* > *Reserve*.
|
||||||
2. Reservations can be cancelled but not modified, as they are saved
|
2. Reservations can be cancelled but not modified nor deleted. To cancel a
|
||||||
in the private traceability log of the devices. To cancel a
|
|
||||||
reservation the user uses the App or the web to select the devices,
|
reservation the user uses the App or the web to select the devices,
|
||||||
and look for their reservation to cancel it. Note that reservations
|
and look for their reservation to cancel it.
|
||||||
are never deleted, but marked as cancelled.
|
|
||||||
3. A reservation is fulfilled once the customer buys, gets through, or rents
|
3. A reservation is fulfilled once the customer buys, gets through, or rents
|
||||||
a device; for example by an e-commerce or through a confirmation e-mail.
|
a device; for example by an e-commerce or through a confirmation e-mail.
|
||||||
To perform any of those actions, a seller selects the devices and clicks
|
To perform any of those actions in Devicehub,
|
||||||
|
a seller selects the devices and clicks
|
||||||
*actions* > *Sell*, *Donate*, or *Rent*. It can perform those actions
|
*actions* > *Sell*, *Donate*, or *Rent*. It can perform those actions
|
||||||
over devices that are not reserved, or mix reserved devices with
|
over devices that are not reserved, or mix reserved devices with
|
||||||
non-reserved devices. Refer to :ref:`actions:Trade`
|
non-reserved devices. Refer to :ref:`actions:Trade`.
|
||||||
to know more about selling, donating, and renting.
|
|
||||||
4. Lots help sellers in keeping an order in sales. A good ordering is
|
4. Lots help sellers in keeping an order in sales. A good ordering is
|
||||||
creating a lot called ``Sales``, and then, inside that lot,
|
creating a lot called ``Sales``, and then, inside that lot,
|
||||||
a lot for each sales, or a lot for each customer.
|
a lot for each sales, and/or a lot for each customer.
|
||||||
5. The seller gets confirmation from the warehouse or refurbisher
|
5. The seller gets confirmation from the warehouse or refurbisher
|
||||||
that the devices have :ref:`been prepared for use <has been prepared for use>`.
|
that the devices have :ref:`been prepared for use <prepare>`.
|
||||||
5. Devices are :ref:`delivery <transported>` to the customer.
|
6. Devices are :ref:`delivered <delivery>` to the customer.
|
||||||
|
|
||||||
Verify refurbishment of a device through the tag
|
Verify refurbishment of a device through the tag
|
||||||
================================================
|
================================================
|
||||||
|
|
@ -376,9 +396,9 @@ Users like refurbishers stick the tags on the devices.
|
||||||
On the end-user side:
|
On the end-user side:
|
||||||
|
|
||||||
1. The end-user wants to verify refurbishment from a device of a retailer.
|
1. The end-user wants to verify refurbishment from a device of a retailer.
|
||||||
2. The End-user sees a QR in a tag, like the the :ref:`tags:eTag`,
|
2. The End-user sees a QR in a tag, like the the :ref:`tags:eTags`,
|
||||||
which scans with its smartphone's QR reader app, taking the
|
which scans with its smartphone's QR reader app, taking the
|
||||||
user to the :ref:`Share device information <public web page of the device>`.
|
user to the :ref:`Share device information <public-webpage>`.
|
||||||
3. The public web page contains, along information about the device,
|
3. The public web page contains, along information about the device,
|
||||||
instructions on how to check the validity of the Photochromic tag
|
instructions on how to check the validity of the Photochromic tag
|
||||||
— consisting on illuminating the tag with the smartphone's lantern
|
— consisting on illuminating the tag with the smartphone's lantern
|
||||||
|
|
@ -393,11 +413,13 @@ for re-use or recycle.
|
||||||
|
|
||||||
Once the customer agrees for the devices to be taken, a transporter
|
Once the customer agrees for the devices to be taken, a transporter
|
||||||
or the same customer takes the device to the warehouse, and an
|
or the same customer takes the device to the warehouse, and an
|
||||||
employee performs a :ref:`Receive` to state that a device has been
|
employee performs a :ref:`actions:Receive` to state that a device has been
|
||||||
physically received, and a :ref:`Trade` to state the change of
|
physically received, and a :ref:`actions:Trade` to state the change of
|
||||||
property. These actions can be performed by scanning the tag with
|
property. These actions can be performed by scanning the tag with
|
||||||
the App or by manually searching the device through the website.
|
the App or by manually searching the device through the website.
|
||||||
|
|
||||||
|
.. _dispose:
|
||||||
|
|
||||||
Dispose a device
|
Dispose a device
|
||||||
================
|
================
|
||||||
Users can manage the disposal of devices in Devicehub. A disposal
|
Users can manage the disposal of devices in Devicehub. A disposal
|
||||||
|
|
@ -427,60 +449,94 @@ Make devices available for sale to final users
|
||||||
==============================================
|
==============================================
|
||||||
Once the devices are registered in the Devicehub, users can share
|
Once the devices are registered in the Devicehub, users can share
|
||||||
the devices to potential customers. Please refer to
|
the devices to potential customers. Please refer to
|
||||||
:ref:`share devices information`.
|
:ref:`share devices information <share>`.
|
||||||
|
|
||||||
Manage purchase of devices with refurbisher / ITAD
|
Manage purchase of devices with refurbisher / ITAD
|
||||||
==================================================
|
==================================================
|
||||||
Please refer to :ref:`Manage sale with buyer`.
|
Please refer to `Manage sale with buyer (reserve, outgoing lots, sell, receive)`_.
|
||||||
|
|
||||||
Distribution of devices
|
Distribution of devices
|
||||||
=======================
|
=======================
|
||||||
Please refer to :ref:`Delivery or pickup from buyer after use`.
|
Please refer to `Delivery or pickup from buyer after use`_.
|
||||||
|
|
||||||
Transport between service providers and buyers
|
Transport between service providers and buyers
|
||||||
==============================================
|
==============================================
|
||||||
Please refer to :ref:`Delivery or pickup from buyer after use`.
|
Please refer to `Delivery or pickup from buyer after use`_.
|
||||||
|
|
||||||
Estimate selling price
|
Estimate selling price
|
||||||
======================
|
======================
|
||||||
Please refer to :ref:`Value (price) devices`.
|
Please refer to `Value (price) devices`_.
|
||||||
|
|
||||||
Manage donations and interactions with donors
|
Manage donations and interactions with donors
|
||||||
=============================================
|
=============================================
|
||||||
- Como solicitar una recogida a donante
|
(Nope)
|
||||||
- Como hacer el convenio y reportes para el donante
|
|
||||||
- Como transferir los dispositivos del donante a uno o varios restauradores
|
|
||||||
- Como redactar la memoria
|
|
||||||
|
|
||||||
Post-sale channel support
|
Post-sale channel support
|
||||||
*************************
|
*************************
|
||||||
|
|
||||||
Customer service for hardware issues
|
Customer service for hardware issues
|
||||||
====================================
|
====================================
|
||||||
Or better said: How to handle after sales issues
|
Devicehub allows introducing contact information in the
|
||||||
|
:ref:`public webpage <public-webpage>` of the device,
|
||||||
|
including an e-mail and phone number.
|
||||||
|
|
||||||
|
This information is based on the default organization, which an
|
||||||
|
administrator sets when installing Devicehub.
|
||||||
|
|
||||||
|
.. todo program this
|
||||||
|
|
||||||
|
.. _warranty:
|
||||||
|
|
||||||
Provide hardware warranty
|
Provide hardware warranty
|
||||||
=========================
|
=========================
|
||||||
|
Devicehub helps in recording the day the warranty is activated by
|
||||||
|
saving in the traceability log the `Delivery`_ of the device to the final
|
||||||
|
user. Specifically, an user can check the last :ref:`actions:Receive`
|
||||||
|
(step 4. of `Delivery`_) to be the one that activates the warranty.
|
||||||
|
|
||||||
Recyclers
|
Recyclers
|
||||||
*********
|
*********
|
||||||
|
|
||||||
Get the certification for recycling
|
Get the certification for recycling
|
||||||
===================================
|
===================================
|
||||||
Please see :ref:`Dispose a device`.
|
Recyclers can obtain a certificate after performing a
|
||||||
|
:ref:`Dispose a device <dispose>` to devices.
|
||||||
|
|
||||||
|
To obtain the certificate, the user scans the tags of the devices with
|
||||||
|
the Android App or searches them through the web, and then selects
|
||||||
|
*certificate* > *recycling*.
|
||||||
|
|
||||||
|
.. todo defined but not programmed
|
||||||
|
|
||||||
Device reuse management
|
Device reuse management
|
||||||
***********************
|
***********************
|
||||||
|
|
||||||
Pick-up at donor
|
Pick-up at donor
|
||||||
================
|
================
|
||||||
Please see :ref:`Manage donations and interactions with donors`.
|
Please see `Manage donations and interactions with donors`_.
|
||||||
|
|
||||||
Transfer donations to refurbishers
|
Transfer donations to refurbishers
|
||||||
==================================
|
==================================
|
||||||
|
(Nope)
|
||||||
|
|
||||||
Get internal custody chain report for donation
|
Get internal custody chain report for donation
|
||||||
==============================================
|
==============================================
|
||||||
|
Users can obtain the internal custody chain report for donation
|
||||||
|
as an comma separated value spreadsheet.
|
||||||
|
|
||||||
|
To obtain the document, the user scans the tags of the devices with
|
||||||
|
the Android App or searches them through the web, and then selects
|
||||||
|
*certificate* > *Internal custody chain report for donation*.
|
||||||
|
|
||||||
|
Users can see part of this information too by selecting *Actions*
|
||||||
|
after selecting a device, resulting in a web view of the traceability
|
||||||
|
log of the device.
|
||||||
|
|
||||||
|
.. todo defined but not programmed
|
||||||
|
|
||||||
|
.. _public-custody:
|
||||||
|
|
||||||
View public custody chain for present devices
|
View public custody chain for present devices
|
||||||
=============================================
|
=============================================
|
||||||
|
The public custody chain of a device is part of the public information
|
||||||
|
of the device that users can :ref:`share device information <share>`.
|
||||||
|
|
|
||||||
Reference in a new issue