To do

Bugs (bekannte Fehler)
Bugs (Codegear)

Baseupdate

//
// todo
//

// * Jede Metadata Modifikation sollte kurz prüfen, ob das Statement selbst
//   in der Datenbank schon realisiert wurde oder nicht - es wäre cool, wenn eine
//   Wissensdatenbank 'Quell-Satements' automatisiert in Ziel-Statements umwandeln
//   könnte. Dazu könnten bestimmte Klassen (list TABLEs , list Fields ,list FK_Check) usw.
//   Oder man könnte mal schnell das Metadatenextract nach den passenden stellen
//   durchsuchen lassen!

// * autoupdate sollte das "Schild" Symbol von Windows XP bekommen

// * autoupdate sollte mehr unter der Haube funktionieren. Nicht so viele 
//   Admin-Schalter die sollten auf die rechner Verwaltung verschoben werden.

// * No-MetaDatachange (neues Feld in der Revisionstabelle): Soll anzeigen ob der aktuelle
//   Release-Sprung ohne Meta-Data Änderung möglichch war? Dann gelten "ältere" Releases
//   als "auch lauffähig" da sie zumindest in der Datenbank keinen Schaden anrichten.

 // 
// * Wenn OrgaMon von aussen beendet wird: wait "OrgaMon" to be down! OrgaMon sollte
//   einen "InsideTRN" Flag pflegen, damit erkannt werden kann, ob gerade eine wichtige
//   längere Aktion vorliegt. Er muss gewartet werden bis zu Ende gebucht ist. So dass
//   das Beenden von aussen nicht "kritisch" ist. Zumindest das eCommerce-Modul sollte so
//   etwas haben.
// * Noch cooler, neben dem check auf ein Undo - also ein "extern" rollback
//   "one single step" <do it statement>:
//     ->  check-statement:boolean; true: "schon erledigt", false "muss ich noch machen"
//     -> do-it-statement:boolean; wie gehabt
//     -> undo-it-statement:boolean;
// * ./Updates Verzeichnis leeren!
// * Released: Ein Flag das gesetzt wird, wenn es diese Version aus einem der Standard
//   Release-Medien stammt. (Developer releases setzen dieses Flag nicht)
// * Problem: Der Entwickler hat in die Rev-Tabelle schon eine neuere Rev Nummer eingetragen
//   diese aber noch nicht released, in so einem Fall sollte sich baseupdate mit einer
//   Release drunter begnügen. Der entwickler muss eine release machen, damit andere
//   weiterarbeiten können.
//

todo Versand
todo System
todo Kunden
todo Belege
todo Artikel
todo Sonstiges
todo Lager
todo Konten
todo WebShop
todo Musikverlag
todo Resourcemanagement
todo ErgoPrax
todo IT-Freiberufler
todo Landschaftspflege
todo Schlosserei
todo MonDa
todo JonDa
todo Geolokalisierung
todo Buchhaltung
todo Mailing
todo i18n
todo SQL
todo amerikanischer Kunde
todo keepcon
todo HTML-Vorlagen

Caretaker

* Zwang zur einer De-Escalationsmassnahme ist absolut notwendig, ev.
  sollte das System stoppen und "Top 5" Massnahmen müssen ergriffen
  werden.

Qualität

• gewisse Zustände gehen ein in die Q-Zahl.
• Die neutrale Froderung ist 100% (besser>100, schlechter<100)
• Es gibt Q-Rubriken, diese bilden die Gesatm Q mit gewisser Gewichtung
• Jede Q-Komponenete sollte anklickbar (und löschbar sein)
• überfällige Mahnungen
• überfällige Zusagen

XML RPC

• JonDaServer Integration in den OrgaMon (XMLRPC)
• Testcase "http://www.orgamon.com/up.php?info=YP86QPYFK"

_to - do (B1/S1, Zwischenversion)

_to - do (B2/S2, grössere Anzahl Anwender)

"B2" ---------

Bug: eine Anzeige die ausgibt, wie viele Postionen in wie vielen Auftr�gen im Überblicksfenster
     aktuell enthalten sind (b) Positionen / Aufträge (63/17)
Bug: Wird ein Suchbegriff überhaupt nicht gefunden, so wird einfach
     alles angezeigt. Besser: Meldung nicht gefunden! B2
Bug: Hauptschirm: Wird ein Suchbegriff Überhaupt nicht gefunden, so wird einfach
     alles angezeigt. Besser: Meldung nicht gefunden!
Bug: F10- Hauptfenster wird sichtbar aber hat den Fokus nicht (was ist da los?) B2
Bug: Themenkomplex: Aufträge ohne Positionen. (Suche, Selektion, neu Berechnen, Owner ...)
     
     Lösung ev. Intern eine Scheinposition automatisch anlegen!

"S2" ---------

Neu: Anwender soll die Möglichkeit haben, die Felder der Tabelle des Auftrags,
     die er sich anzeigen lassen möchte, auszuwählen. Version 2
Neu: Die Sortierung im Positionsfenster soll (klick auf alle Tabellentitel) frei wählbar sein.
     S2
Neu: Hauptschirm und Auftrag mit Menüs, die alle Aktionen anbieten 
     (noch mal durchsprechen bq 09/02) .
Neu: DB-Locking Auftrags-weit! Oder Überprüfung, wer letzte Änderung mit 
     interner Nummer auch im Hinblick auf Änderungsverfolgung ???? bq 09/02 S2
Neu: (Nachtrag zur Rev. 1.016) (12.03.02) mehrere Fenster öffenbar
     (experimentell:verwirklicht bei Tastenkombination <Strg>&<ENTER> -> 
     Liste der offenen Fenster dazu S2
Neu: Im Kalender muss es möglich sein Arbeitstage als arbeitsfrei (Betriebsschließung, 
     Kurzarbeit) zu kennzeichnen. S2
Neu: Profile kopieren S2
     (12.03.02) Einfache Distribution vorbereiten: 1. prüfen auf "easy install"
     (19.03.02) neuer SystemParameter
             UPDATEPATH=
             (UNC-Pfad sollte möglich sein)
             Einfache Distribution vorbereiten: Anwendung älter als Datenbank?
             Systemparameter einführen für eine Setup-Maske (Pfad Maske). Neueste
             Version wird ermittelt, das Setup-Programm wird gestartet.
             Danach muss es der Benutzer nochmal versuchen!
     (13.03.2002) Auftrag: Die Auftragsnummer soll die laufende Nummer aus dem
             Übersichtsfenster sein und deshalb hier bei Aufruf eines Auftrags
             ausgegeben werden (s2)
     (13.03.2002)Auftrag:Das Feld Lieferant muss natürlich positionsbezogen sein
             (sorry) => Es kann aus den Kopfdaten entfallen und muss bei den
             einzelnen Posten editierbar sein (s2)
     (19.03.02) Gruppe: Das Feld Gruppenkuerzel reicht uns noch nicht aus.
             Erweiterung auf 40 Zeichen oder mehr (s2)
     (19.03.02) Gruppe: 3. Im Feld Bearbeiter bitte den vollen Namen aus dem
             Bearbeiterfenster anzeigen (s2)
     (23.4.2001) Anforderung : Im �berblicksfenster soll es m�glich sein alle Felder des
             Auftragskopfes flexibel zur Anzeige auszuw�hlen. Die Anforderung,
             dass die Ausgabe nach allen Auswahlfeldern sortierbar sein soll, bleibt bestehen.
     (23.4.2001) Fehler im Auftragsfenster: bei überschreiben einer Pos und anschliessendem
             Klicken in ein leeres Feld wird der Feldinhalt des Ursprunsfeldes
             mit dem neuen Inhalt überschrieben und kann nicht rückgängig gemacht werden.
Neu: (07.05.02) Farbmarkierung des Hauptschirms auch in die Posten übernehmen, so dass
             erkannt werden kann bei welchem Meilenstein der Verfall seine Ursache hat.

_not - to - do "L" (längerfristig machen & Visionen)

"L" ---------

Idee: Bewertung der Owner im Rahmen des Tagesabschlusses.
      1) bestimmung der Anzahl der aktiven Zeilen
      2) bestimmung und bewertung der Zeilen im Verzug
      -> bei Arbeitsvolumen x gab es y Verfehlungen! (an diesem Tag)
         Prozentwert daraus berechenbar. 100% gut
         0% gar nix

      (12.03.02) Auftrag als html Dokument ausgeben, die Meilensteine in horizontaler
             Form, solange alles noch im Plan ist mit einer anderen Farbe hinterlegt,
             ansonsten ist der "Handlungsbedarf" besonders markiert. (Abgearbeitet
             in einer anderen Farbe)
             Dokumentverzeichnisse für die Aufträge als Ablage
Neu: (zz) neben dem errechneten ABSCHLUSS, sollte es auch ein ABBSCHLUSS_WUNSCH
             geben, der die Farben stärker bindet wie der ursprünglich geplante. Also
             liegt ABSCHLUSS bei 15.06.2003, man verspricht aber den 01.06.2003 so
             das System Positionen des Auftrags frühzeitiger in den Status "rot"
             versetzen wie die ursprüngliche Planung eigentlich vorsieht. Ob es
             reicht alle "DAUER" felder prozentual zu verringern bleibt offen.
Neu: (zz) Im der Phase lassen sich ja Datenfelder in der Art "INVENTURNUMMER="
            eingeben, die werden in die Meilensteine übernommen, hier kann ein
            Zusätzlicher Eintrag von Daten erfolgen, es sollen Zwangsfelder hier
            bei markierbar sein (ev. durch "*" Muss-Feld!) der Eintrag "ABSCHLUSS"
            ist im Meilenstein erst möglich wenn diese Felder gesetzt sind.
     (08.03.02) mit dem Cursor ganz nach unten, dann neue Zeile ->
     (08.03.02) Bei Neuanlage, letzte Pos# + "1"
     (08.03.02) ersten Neulage, gleich "1"
     (08.03.02) Bemerkung oben beim Auftrag ev. Full Screen Knopf.
     (30.05.02) (neu) 4) Konzept - "Easy-Update". die client Installationen werden ja jetzt auf
            C:\programme\.. usw. durchgeführt (also lokal!!) - richtig? Das Programm merkt ja
            (sollte es selbst eine alte release sein) an der Datenbank, dass diese schon mal
            eine neuere Release gesehen hat. Wenn jetzt ein Pfad angegeben ist, (den alle
            relaxx-Clients sehen) wo die aktuellen setups drinliegen könnte sogleich der setup
            für das neueste release gestartet werden (und danach wieder die neueste release).
            Würden Sie so eine Vorgehensweise unterstützen? (München sorgt dann nur noch für
            den relaxx-grund-dienst, wir selbst für die aktuellste Version).
            -> nehmen wir an ich hab mal Mist gebaut, und alle user müssen zurück auf eine alte
            release, das könnten wir mit einem "Easy-Install" auch realisieren 
            (-> 1.) datenbank
            ist älter, 2.) eigene Release ist nicht mehr als setup vorhanden!! ) Auf alle Fälle
            muss ich aber noch dokumenieren, wie man eine Release zurück gehen kann (in der DB
            die Tabelle "REVISION").

--> nächste rev

Neu: Damit man besser testen kann, kann der Admin im relaxx.ini angeben als
     welcher User er sich einloggen will.

     Role=fax29383

Versand

Beleg: Versandtag (Datum) (mögliche Versandtage: Mo,Di,Mi,Do,Fr)

       Auslieferungstag (mögliche Tage: Mo,Di,Mi,Do,Fr,Sa)
Zollcode: Summe des Wertes (wie es dasteht) über die Sortimente
Post, Parameter abhängig vom Wirtschaftsraum
P1_Deutschland
P2_Deutschland
P1_EU
P2_EU
  (Wareneingang muss "vorgebucht" sein, eigentlich sollte man jedoch alles
   nur einmal in die Hand nehmen)

  Ansicht schaltbar: versand-orientiert (Alles wegsenden)
                     Lager-Übergangsfach-orientiert (Alles gut vorbereiten)
                     Wareneingangs-orientiert (Alles wegschaffen)
  Top 1 ---------------------
          direkte Zuordnung Wareneingang zu versandfertigen sachen
          (Anliegen:versenden!!!)
  Top 2 ------
          wandert in Übergangsfächer
          (Anliegen:richten für morgen!!!)
  Top 3 ------
          wandert ins Lager
          (Anliegen:richten für fernere Zukunft!!!)

SYSTEM

• SetContext: wenn nicht sichtbar show / wenn nicht gross, auf normal gehen (gross machen)
• Datenbank: Logik-Log zur Diagnose, dabei lassen sich zu allen Logik-Routinen (ev. organisiert in Gruppen) die Log-Funktion ein oder ausschalten.
• Datenbank: Error-Log zur Speicherung von Fehlerzuständen.
• Ausgabe von html-Dokumenten:

  @page info (im html!!!) macht auch OpenOffice!!
   http://www.w3.org/TR/REC-CSS2/page.html

• Langfristig Ich will folgende Dienste ganz ohne Schnickschnack als reine

   eCommerce-Module umprogrammieren (die können dann später auch unter linux
   laufen) Im Moment sind sie fest ins OrgaMon eincompiliert:
 * XML RPC Kylix

 - xml-rpc dienst (24h)
    * dazu muss "eCommerce" völlig "vcl" frei programmiert werden!
    * dazu muss die Beleg-Berechnung / Übernahme / Anlage völlig von belege.pas
      entkoppelt werden!
    * dazu muss xml-rpc mit einem neuen "Indy 10" tcp-Server programmiert werden!?
 - pdf mailer (24h)

 - backup Erstellung
    * mal forschen, wie läuft das unter kylix
 - indexerstellung für Artikel und Personensuche
    * das modul entsprechen kylix fähig machen (das ist ev. der erste schritt!)
 - andere Dienste des Tagesabschlusses, sowie der Tagesabschluss selbst
    * das ist ev. zu schwierig!

• der defekt eines Dienstes darf dabei den anderen Dienst nicht mit in den

   Abgrund ziehen. Das ist im Moment so!!! (Dienst Trennung)

• Dienste sollte eine Anfrage der Datenbank nach Disconnect reagieren können.

   Dann sollten sie in einen Offline Status gehen können.

• die 24h-Dienste sollten langfristig auf linux umziehen, da sie dauernd

   erreichbar sein müssen.

• die anderen Dienste sollten aus OrgaMon selbst in kleine Miniprogramme

   verlagert werden, die diese Aufgaben im Hintergrund nacheinander ausgeführt werden,
   während OrgaMon weiter dem Benutzer zur Verfügung steht. Dazu könnte man
   einen OrgaMon-Agent erfinden, der auf Befehle des OrgaMon lauert...

• Massnahmen für schnelleres "Server Hopping": Der Störungsfall BILL hat gezeigt, dass eine Rekonstruktion schnell möglich ist.

• Neu: Preise: Es kann nun auch für spätere Ausgabearten ein Preis ermittelt

     werden.

• Neu: Order: neue Spalte "Einzel_VK", zu erwartender Einzel-VK-Preis. Wird bei

     Wareneingang auch so in den Beleg übernommen, bzw. der Wert dort
     überschrieben.

Kunden

• Kunde: Datum der Probe (niedrige prio) PROBETAG, Versandtag := Probetag - 2 Versandtage
• noch kein richtiges Konzept für die Adress-Varianten: Personen: Kontakt muss auf die erste Lasche. Vorschlag die untere Hälfte entsprechend verkleinern. Bei der Anschrift (Str. Ort) müssen mehrere Adressen (Nr. 1, 2...) hinterlegt werden, die beim Auftrag auch gezogen werden. Christian: 2.Adresszeile für Kunden, so dass man hier "Musikverein "Echo"" eintragen kann. Diese Schreibhilfe sollte addierend sein! Ev. in den Kunden in ein Textfeld übernehmen! Alternativ-Adresse angebbar im Beleg (Musikverein a, Musikverein b)