This is the identifier (salesordernumber) that is assigned when the
salesorder is received. In many cases, this is what we'll need to
transfer instead of the final salesorder number, which is produced days
or weeks later when the salesorder is finally sent.

The raising of exceptions when posting batches results in the
Unknown-status never beeing returned from the API. Aditionally, it
exposes transport specifics out of the client module. One should only do
one of them, not both. Exception raising when posting sales orders is
now removed.

The ordenr_ubw attribute is never sent in, only returned by the Setra
API. The model handles both input and output of salesorders, so we'll
have to mark the attribute as optional and 

The order number is transferred along with the status of import back to
BookitLab.

it will not fill these field, because they are not yet available, and therefore it would fail when parsing the data 

setra was crashing because wrong parameters was used to search for batches

requests.exceptions.JSONDecodeError is non existent in requests versions
before 3.0.0. Therefore requests is pinned to 2.24 or greater, and we
use ValueError instead of requests.exceptions.JSONDecodeError.

This commit makes the interface of put_update_batch() quit similar to
post_new_batch().

The Setra API does not accept null values for attributes, but it accepts
that the attribute is omitted. We should probably accept null values
for fields in order to avoid obscure bugs like this, but it does not
hurt to omit the values.

At least we use less of the bandwidth! :)

Exclude unset values from beeing transfered when posting a new batch to
Setra. Setra does not accept fields set to None (at least period and
vouchertype).

This interface avoids leaking transport-specific information, while
returning an indication of how the request fared so the user can decide
on how to proceed with processing.

Before this commit it was unclear whether a post request was successful
or not. We now return the content and status to make this clearer

Setra supports vouchertype being optional, so the client should as well.

This allows more readable code, as we can do

  if batch.batch_progress == BatchProgressEnum.VALIDATION_FAILED:

instead of

  if batch.batch_progress == str(BatchProgressEnum.VALIDATION_FAILED):

or

  if batch.batch_progress == BatchProgressEnum.VALIDATION_FAILED.value:

Validation rule 12 defines period as an optional field. If empty, it
will be populated by master data.

Instead of mixing the Batch model for batches sent *to* with batches
received *from* SETRA, we switch to using an InputBatch and an
OutputBatch. The InputBatch contains the fields that can be used when
sending a Batch (with Vouchers and Transactions), and the OutputBatch
contains all the information one receives from SETRA when fetching a
single batch from the batch/ endpoint, or multiple using the search
functionality.

The get_batch method is reduced to only fetch a single batch, while the
new search_batches method takes the role of searching based on creation
date and interface. In addition, the return_list_of_obj parameter is
removed in favor of the return_objects class attribute.

This commit expects that SETRA includes the id field in Batches.

Also a little tidying

Instead of two methods we now have one that does the appropriate
action based on the input type.