Prescription tasks returned in more than one state by erpione

[alisianoi]

Steps to reproduce:

# Pull the image, start a container with a valid API KEY:
$ docker pull gematik1/erpione:0.2.1
$ docker run -it --entrypoint /bin/zsh --env ERPIONE_API_KEY=${ERPIONE_API_KEY} gematik1/erpione:0.2.1

# Get the list of open prescriptions for my KVNR:
$ erpione fetch open --env ru --kvnr F133333337
Found 13 open prescriptions with filter KVNR=F133333337
----------

# Choose one prescription task, and accept it:
erpione accept --env ru --taskid 200.000.002.095.415.08

Expected:

An "open" prescription task should get accepted successfully.

Observed:

An "open" prescription task was actually not "open", but already "complete" (aka "dispensed").

2024-02-08 08:09:21,650 [rest_client.pyc     ] ERROR: 409: unknown error:
{"type":"FACHDIENST","message":"[ERROR] Task has invalid status completed: null"}

Would it be possible to return prescription tasks only in that group which corresponds to their actual state? Otherwise, a "complete" (aka "dispensed") prescription task is returned in all groups: "open", "accepted" and "dispensed".

[alexanderkaiser]

Is it possible, that the prescription was dispensed via an external system? In those cases our backend cannot keep track of changing states.

For clarification, the fetch command is intended for informational purposes only. Usually the workflow is intended to be used as prescribe -> accept -> dispense

Anyway, I'll try to figure out an approach on how we could keep track of prescriptions states without permanently polling the FD.

[alisianoi]

Is it possible, that the prescription was dispensed via an external system?

No, all my prescription tasks were created using erpione up to this point.

Anyway, I'll try to figure out an approach on how we could keep track of prescriptions states without permanently polling the FD.

Well, I opened this bug primarily to show/point out a UX issue. If the solution is to introduce a cache in-between the user of erpione and the Fachdienst, then personally I am happy to agree to close this bug as "wontfix".

[alexanderkaiser]

No, all my prescription tasks were created using erpione up to this point.

Okay, in this case it's indeed an issue, which I can also reproduce. I assume it's an issue with the state-handling on the PrimSys-Backend.
I will definitely try to fix this one for the next release of the PrimSys. Thank you for reporting 👍

Addendum: definitely an issue with the PrimSys. When you do prescribe -> accept you'll find your prescription in both groups open and accepted. The same issue applies to dispense: while moving the prescription from group to another the PrimSys is missing the remove-operation on the original group