EBICS 3 tutorial: moving sections.

3 files changed, 23 insertions, 22 deletions

diff --git a/libeufin/check-payment-subject-0.png b/libeufin/check-payment-subject-0.png
new file mode 100644
index 00000000..eb8c8ca5
--- /dev/null
+++ b/libeufin/check-payment-subject-0.png
diff --git a/libeufin/check-payment-subject-1.png b/libeufin/check-payment-subject-1.png
new file mode 100644
index 00000000..eb99cf20
--- /dev/null
+++ b/libeufin/check-payment-subject-1.png
diff --git a/libeufin/ebics3-test-tutorial.rst b/libeufin/ebics3-test-tutorial.rst
index 5f08e15b..3dc1fe7c 100644
--- a/libeufin/ebics3-test-tutorial.rst
+++ b/libeufin/ebics3-test-tutorial.rst
@@ -109,6 +109,9 @@ the user check them.
 Setting up the local Docker and run the test
 --------------------------------------------
 
+This section shows how to run the test and explains how to interact
+with the test runner.
+
 Clone the following repository:
 
 .. code-block:: shell-session
@@ -129,11 +132,6 @@ and build the Docker image with the following command:
 
 If the previous steps succeeded, the *pofi* image is ready to be run.
 
-.. note::
-  
-   Although the test runner guides the user via live instructions,
-   it's advised to read the `Test details`_ section.
-
 The test runner needs the following three values: EBICS user ID, EBICS
 partner ID and IBAN.  The `previous section <get-ebics-ids_>`_ explains how
 to get the EBICS IDs.  The IBAN is the one entered `here <my-iban_>`_.
@@ -159,19 +157,8 @@ via the traditional paper mail.
 After having confirmed the new keys, the execution can be resumed to
 let the test runner proceed with the uploading and downloading operations.
 
-Test details
-------------
-
-The first operation is the key exchange with the bank.  EBICS has
-encrypted and signed communication from both client and server; for
-this reason the client will send its keys to the bank, and viceversa.
-
-Note: after the client sends its keys to the bank, those should
-be confirmed via another channel; usually that's done via a ordinary
-paper letter but in this case the test platform allows such confirmation
-via the Web interface.  Therefore, after having uploaded the client
-keys to the bank, the test runner pauses the execution to let the
-user confirm the keys via the Web interface.
+Upload
+======
 
 After the key exchange, the test runner continues by uploading one
 payment instruction.  The payment instruction is a ``pain.001`` document
@@ -184,12 +171,26 @@ A chance to specify a custom subject is also offered by the test runner.
 
 After the upload to the bank, the execution pauses to let the user
 check whether the test platform has received the payment instruction.
-The following screenshot shows where to look for such check:
 
-.. image:: check-payment-subject.png
+Click on the following navigation item:
+
+.. image:: check-payment-subject-0.png
+
+the opened page should look like the following:
+
+.. image:: check-payment-subject-1.png
+
+in this case, open the (archive) file whose timestamp corresponds to the
+test execution and look for one XML file whose name contains "pain.001"
+(likely, this XML file is named after the archive's name).  If found,
+the pain.001 file is expected to contain one node called ``Ustrd``: that
+is the payment subject and must match the one that was specified by the
+test runner.
+
+Download
+========
 
-At this point, the upload operation ended and the execution can proceed
-to test the download.  The download tries to get one ``camt.054`` (as well
+The download tries to get one ``camt.054`` (as well
 ISO20022) document from the bank; this document is expected to account
 for the previous outgoing payment that was created via the pain.001.  As
 in the pain.001 case, EBICS is responsible to transport the camt.054 from