delete_design_draft.py

# Skizze, wie das Löschen und Entlöschen eines Belegs in etwa funktionieren soll
# die Funktion basiert darauf, daß der Inhalt des Feldes "KASSENNAME" in weiteren
# Prozeßschritten definitiv nie benötigt wird
# außerdem wird das Image in der IBF-Datei nicht wirklich gelöscht, sondern erhält
# nur eine andere PIC-Nummer, die es so definitiv auch nie geben kann. Somit ist
# ein Entlöschen sowohl des Belegs als auch des Images problemlos möglich. Durch
# das Ändern der PIC-Nummer ist sichergestellt, daß das Image in nachfolgenden
# Prozessen wirklich nicht gefunden werden kann
class CDB_Form(object):
    def delete(self):
        # 1. die Belegnummer kommt in das Feld "KASSENNAME" (der alte Inhalt wird verworfen)
        # 2. die kurze und die lange Belegnummer werden auf den Wert "DELETED" gesetzt
        # 3. Beleg zurückspeichern
        # 4. in der IBF-Datei bei der Belegnummer die letzten 3 Stellen von "024" auf "999" ändern
        
    def is_deleted(self):
        # return Belegnummer == "DELETED"
        
    def undelete(self):
        # 1. in der IBF-Datei bei der Belegnummer die letzten 3 Stellen von "999" in "024" ändern
        # die Belegnummer aus dem Feld "KASSENNAME" in die kurze und lange Belegnummer kopieren
        # das Feld "KASSENNNAME" bekommt den Inhalt "UNDELETED"
        # Beleg zurückspeichern

Habe nach viel Überlegung doch einige Probleme.

1. Warum die IBF überhaupt ändern? Reicht es nicht, wenn die Verbindung zur CDB gebrochen wird, also die CDB eine falsche 999-Nummer erhält? Bzw. ist die Verbindung ja schon durch "DELETED" unterbrochen. Wer greift denn überhaupt direkt auf die IBF zu und würde explizit nach einer 024-Nummer suchen?

2. Die IBF-Datei wird doch im CDB-Zustand nur gelesen. Was für Programme greifen denn überhaupt noch auf das Image zu? Alles relevante steht doch in der CDB.

3. Ich könnte doch statt den Kassennamen (oder prinzipiell irgendein Daten-Feld) zu missbrauchen, was beliebiges in die lange Belegnummer schreiben, z.B. dort den Zustand merken, statt nur DELETED reinzuschreiben. Meinetwegen "DELETED xxx" wobei xxx ein beliebiger Text sein kann?

4. Worum geht es Dir, wenn "undeleted" eingetragen wird? Willst Du dass es deutlich in den Daten steht, oder willst Du dass es EdiView als deleted anzeigt? Wenn ich das wüsste könnte ich es besser umsetzen. Es fällt mir leichter, im GUI "deleted" anzuzeigen als es irgendwo reinzuschreiben.

5. Aus der Beschreibung wird nicht eindeutig klar, was Du meinst: es wird sich auf "PIC_NR" bezogen. Das Feld gibt es aber nur als Benennung in der CDB:

   @Property
   def pic_nr(self):

   • return self.form_header.rec.imprint_line_short

   aber Du sprichst wohl doch von der IBF.

   Was ich gern möchte ist eine Eindeutigkeit. Auch wenn der Wechsel von "024" auf "999" etwas willkürlich erscheint, möchte ich das explizit irgendwo hinschreiben, sodass das konsistent und rückwärtskompatibel bleibt, auch wenn wir es irgendwann anders machen. Deswegen plane ich das Umbenennen in der IBF, wenn denn nötig, als eigenen Teilschritt, der konsistent bleibt.

6. Wer schreibt ausser uns noch in die CDB/IBF? wenn das niemand sonst ist, dann kann ich den undefinierten Teil eines Feldes ausnutzen und dort Info hinterlegen, aber nur dann (andere Programme könnten das sonst zerstören).

7. In der IBF steht in IDENTIFIER immer "REZEPT", in CODNR steht immer die kurze Nummer. Das könnte wunderbar missbraucht werden, entweder durch längeren Text (aber da warst Du wehement dagegen), oder mit dem transparenten Trick aus 6., aber dazu weiss ich nicht ob noch einer schreibt. Wird der REZEPT-Text irgendwo ausgewertet, oder darf ich was dazuschreiben?

Zur Vorerklärung: Einige Sachen machen wir schon mit Hinblick darauf, daß EdiView mal Pydica wird und dann unseres bisheriges Uralt-Programm ersetzt. Dies wird aber nicht auf einen Schlag gehen - ich vermute, daß das 2-3 Monate braucht von der ersten Release mit Validatoren bis zu einer Version, wo wir das Uraltprogramm entsorgen können.

Am Anfang werden sicherlich nur Franziska und ich mit Pydica arbeiten und dann bekommen es auch die anderen. Ich möchte nur jederzeit in der Übergangsphase die Möglichkeit haben, die Uraltsoftware noch einzusetzen, da wir gerade um den Monatswechsel kaum Zeit haben, um Fehler oder Erweiterungen im Livebetrieb zu fixen.

Einige Anforderungen resultieren also daraus, daß ich zumindest bis zu dem Zeitpunkt, wo wir die Uralt-Software entsorgen, eine größtmögliche Kompatibiltät haben will - unter der Nebenbedingung, daß wir ein Minumum an Wissen haben, was die Uralt-Software anbelangt.

Sobald nur noch Pydica statt der Uralt-Software eingesetzt wird, können wir sicherlich die eine oder andere Sache überdenken.

Nun zu den einzelnen Fragen.

I. Warum die IBF überhaupt ändern? Reicht es nicht, wenn die Verbindung zur CDB gebrochen wird, also die CDB eine falsche 999-Nummer erhält? Bzw. ist die Verbindung ja schon durch "DELETED" unterbrochen. Wer greift denn überhaupt direkt auf die IBF zu und würde explizit nach einer 024-Nummer suchen?

II. Die IBF-Datei wird doch im CDB-Zustand nur gelesen. Was für Programme greifen denn überhaupt noch auf das Image zu? Alles relevante steht doch in der CDB.

III. Ich könnte doch statt den Kassennamen (oder prinzipiell irgendein Daten-Feld) zu missbrauchen, was beliebiges in die lange Belegnummer schreiben, z.B. dort den Zustand merken, statt nur DELETED reinzuschreiben. Meinetwegen "DELETED xxx" wobei xxx ein beliebiger Text sein kann?

Im Prozeß werden noch wesentlich später - erst nach der Abrechnung - Images erstellt. Dabei wird - auch durch eine andere Uralt-Software - über alle IBF-Dateien der Abrechnung ein Index erstellt, der dann im Weiteren verwendet wird, um die Images schneller zusammenzustellen.

Nun wäre es zwar kein Problem, wenn die eigentlich gelöschten Nummern noch in den IBFs und damit im Index drin sind. Allerdings ist das für mich eine Art Nachkontrolle der Abrechnung - nämlich, ob irgendwo in den Prozessen was nicht erwünschtes passiert ist. Das könnte zum Beispiel sein, daß ein Rezept abgrechnet wurde, was eigentlich gelöscht wurde (in der CDB), aber aus irgendwelchen Gründen diese Löschung nicht in nachfolgende Prozesse übernommen wurde. Wenn dann das Image noch in der IBF-Datei drin ist, bekomme ich das nie mit, ist es nicht mehr drin (oder eben nicht mehr über den Index auffindbar, weil das Image eine andere Nummer hat), dann bekomme ich es wenigstens durch eine Fehlermeldung mit.

Dann ist das Kind zwar schon in den Brunnen gefallen - aber noch nicht ertrunken, weil ich es rechtzeitig gefunden habe. ;-)

Ach so, vielleicht noch wichtig zu wissen: Mein Abrechnungssystem kümmert sich nicht um die CDB-Dateien, sondern nur um die ASC-Dateien.

Ich habe zwar an vielen Stellen schon Prüfungen drin, die eigentlich immer aus erkannten Problemen entstanden sind, aber es gibt halt immer wieder mal was neues, an was ich noch nicht gedacht hatte, was auch abgeprüft werden muß. In der Abrechnung 01/2013 ist wieder mal (seit langem) so was passiert, weil ich gezwungenermaßen in den CDB-/IBF-Haushalt per Hand eingegriffen hatte und die Mitarbeiter da auch gleichzeitig was gemacht hatten. Jedenfalls war da wieder was, was ich bisher nicht abgeprüft hatte. :-/

Ja, also deswegen sollen die Images, die gelöscht sind, unter ihrer eigentlichen Nummer nicht mehr auftauchen, damit die bisher existierenden Prozesse nach wie vor funktionieren.

IV. Worum geht es Dir, wenn "undeleted" eingetragen wird? Willst Du dass es deutlich in den Daten steht, oder willst Du dass es EdiView als deleted anzeigt? Wenn ich das wüsste könnte ich es besser umsetzen. Es fällt mir leichter, im GUI "deleted" anzuzeigen als es irgendwo reinzuschreiben.

Eigentlich beides: Die Uralt-Software stört sich nicht an dem Eintrag im Kassennamen und wird das Image auch nicht anzeigen können (sie hat ja kein Wissen darüber, daß die alte Nummer im Feld Kassenname steht). In EdiView kann natürlich direkt angezeigt werden, daß das Image gelöscht ist, denn das kennt ja die "Tricks".

V. Aus der Beschreibung wird nicht eindeutig klar, was Du meinst: es wird sich auf "PIC_NR" bezogen. Das Feld gibt es aber nur als Benennung in der CDB:

• @Property
  def pic_nr(self):
• return self.form_header.rec.imprint_line_short

aber Du sprichst wohl doch von der IBF.

Was ich gern möchte ist eine Eindeutigkeit. Auch wenn der Wechsel von "024" auf "999" etwas willkürlich erscheint, möchte ich das explizit irgendwo hinschreiben, sodass das konsistent und rückwärtskompatibel bleibt, auch wenn wir es irgendwann anders machen. Deswegen plane ich das Umbenennen in der IBF, wenn denn nötig, als eigenen Teilschritt, der konsistent bleibt.

Ja, das ist eine Problem: Ich (und wir und die Kassen und die Apotheken) nutzen die Begriffe PIC-Nr., CodNr, kodierte Nummer oder auch Belegnummer - da ist aber immer das gleiche gemeint.

VI. Wer schreibt ausser uns noch in die CDB/IBF? wenn das niemand sonst ist, dann kann ich den undefinierten Teil eines Feldes ausnutzen und dort Info hinterlegen, aber nur dann (andere Programme könnten das sonst zerstören).

VII. In der IBF steht in IDENTIFIER immer "REZEPT", in CODNR steht immer die kurze Nummer. Das könnte wunderbar missbraucht werden, entweder durch längeren Text (aber da warst Du wehement dagegen), oder mit dem transparenten Trick aus 6., aber dazu weiss ich nicht ob noch einer schreibt. Wird der REZEPT-Text irgendwo ausgewertet, oder darf ich was dazuschreiben?

Siehe oben - bis zur vollständigen Ersetzung kann jederzeit die Uralt-Software schreibend auf die CDB-Dateien zugreifen.

Was auf alle Fälle intakt bleiben muß, ist die in der IBF-Datei steckende TIF-Datei, denn da weiß ich nicht, wie von der anderen Uralt-Software weiterverarbeitet wird. Die daraus entstehenden TIFF-Dateien werden u. a. an die Krankenkassen geliefert und da habe ich keine Lust, durch eine Änderung Imagedaten für mehrere Monate nachliefern zu müssen (zumindest momentan nicht, habe genug um die Ohren).

Ok, ein Image wird ja nur dann geliefert, wenn es nicht gelöscht wurde - insofern müßte nur sichergestellt sein, daß eine gelöschtes und dann wieder entlöschtes Image (bzw. die in der IBF enthaltene TIF-Datei) genau so aussieht wie vorher.

Hm, hoffe erstmal halbwegs geholfen zu haben. Rufe mich bitte an, falls noch was zu klären ist - macht sich sicherlich am Telefon besser.

Als Essenz (vor dem Essen, nachher mehr) kommt für mich erstmal heraus:

• das Umbenennen der IBF-Entries ist notwendig
• was in der CDB steht, ist relativ zweitrangig - wichtig ist was der Ascii-Export sieht. Das verkleinert das Problem erheblich: Für Ascii filtere ich gerne was Du willst.
• Uralt-SW kann auf CDB noch nach??? Pydica zugreifen, sicher? Also keine Tricks mit den Feldern.
• die Images verstecke ich. In dem Zustand (nicht auffindbar wg. 999) sind die anderen Felder frei änderbar, nach undelete muss alles wieder stimmen

Aber CDB und IBF sind schon eindeutig zugeordnet und Du schiebst mir keine andere unter? ;-)