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)
Belege
- Beleg individuelle Zahlungsarten einführen. Sie sollten vorrang vor der Standard-Zahlungsart im Kunden haben.
- Abschaffung von "AUSGANGSRECHNUNG", Ersatz durch "BUCH"
- Abschaffung von BELEG.RECHNUNGSBETRAG und BELEG.DAVONOFFEN
- Storno bzw. Rechnungskorrektur "minus mengen" SETZT NICHT REC AUF GELIEFERT"
- menge AA-Probestimme ist unendlich, wenn ..\Probestimme vorhanden.
- eMail für versand von Artikel "A" an Kunde "P"
- Alexander: Bestellbeleg sollen als Infofeld erhalten, wie genau die Anzahl zusammen
gestellt ist:
[] zur Erreichung des Mindestbestandes
[] zur Befriedigung von Kundenbestellungen
[] frei aufaddierte/verminderte Anzahl
==========
[] tatsächliche Bestellmenge
Artikel
- Bestandshistorie für einzelne Artikel - ev. in ein Memo-Feld!
- Artikel: neues Feld "Kapitel", danach auch selektion
Sonstiges
- einfacher Wechsel zwischen offenen Fenstern anhand einer Tastenkombination
Lager
* "A" Taste für einen Lagerplatz * "B" Taste für einen Übergangsfach-Lagerplatz * Warenbewegungshistorie für einen Lagerplatz
-> umstellen: "VERLAG_R" im Artikel muss auch wirklich auf die Verlage zeigen! -> Thema "freies Lager" -> Thema "ShowRoom" -> Thema "Verlags Volumen"=2, also Stücke die 2 Fächer in anspruch nehmen. -> Thema
Kommissionierliste für Übergangsfächer erstellen. (Nach Wareneingang bzw. bei Bestellungseingang, wenn noch keine Lieferung erfolgt !)
Rechnung Die Lieferung erfolgt mit .....
Kundenauftrag automatisierte Information an den Kunden, wenn am Tag der Bestellung keine Lieferung an den Kunden rausgeht (Auftragsbestätigung) und zwar per e-mail oder fax.
Verlagsstatistik monatliche Verkaufsstatistik der verkauften Artikel eines Verlages. (Soll dem Verlag) per e-mail zur Verfügung gestellt werden)
* ev. Prüfen wie "alt" ein Übergangsfach ist. Art Verfallsdatum, das
warnt, wenn es erreicht ist. ev. zusage auch im Übergangsfach=Verfalssdatum.
6.1.2004: Eigentlich muss das komplett über die Zusage gelöst werden, im
Ergebnis ist natürlich eine Liste der größten Versäumnisse bei
Zusagen möglich. Die Beleg liegen aber nicht notwendigerweise in
einem Übergangsfach (es kann ja ein Totalausfall an Lieferbarkeit
sein).
LISTE der belegten Übergangsfächer:
select L.NAME from beleg B JOIN LAGER L ON B.LAGER_R=L.RID where LAGER_R IS NOT NULL
Zuteilungsmoment ist im Moment nicht bestimmbar. Es gibt aber im eCommerce nur 2 zentrale Punkte für "Eintrag" und Release!
* "räuberische Übernahme": Artikel im Übergangsfach eines anderen zur räumung anbieten und übernehmen! (z.B. wegen einer entspannteren Zusage beim Kunden B) * ev. Funktion zur absichtlichen Ablage in ein Übergangsfach (Bestellung auf einen gewissen Termin?!) Verzögerte Auslieferung. Eintrag des Wunsch- auslieferungstermin.