To do: Unterschied zwischen den Versionen

Aus OrgaMon Wiki
Zur Navigation springen Zur Suche springen
Keine Bearbeitungszusammenfassung
 
(174 dazwischenliegende Versionen von 7 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
[[todo Versand]]<br>
[[Bugs|Bugs (bekannte Fehler)]]<br>
todo "System"


  * In der Datenbank: Logik-Log zur Diagnose, dabei lassen sich zu allen
== Warenwirtschaft ==
  Logik-Routinen (ev. organisiert in Gruppen) die Log-Funktion ein oder
 
  ausschalten.
=== "offene Order" ===
* In der Datenbank: Error-Log zur Speicherung von Fehlerzuständen.
 
  * Ausgabe von html-Dokumenten:
Warenannahme
   @page info (im html!!!) macht auch OpenOffice!!
 
* <s>soll zunächst aus offene Belege kopiert werden</s>
* Ablauf
** <s>Artikel-Scan, Suche in den erwarteten Mengen, </s>
** <s>Darstellung der ganzen anderen Erwarteten des beleges</s> (Farben verwenden)
** <s>pro 1 Scan bei erwartete Menge=1: das ist analog zu Drücken von einem [W] </s>
** <s>sind es mehrere wird gewartet bis alle gescannt sind, danach erst die Buchung</s>
* Bei der Annahme soll kontrolliert werden
** <s>GTIN (wie bisher)</s>
** Artikelbild nachlesen, wird anhand eines Scanners geliefert, Verzeichnis soll konfigurierbar sein, VErzeichnis soll im Hintergrund geprüft werden bis Bild da ist
** Gewicht nachlesen, wenn leer oder 0, USB Waage soll hier angeschafft werden (http://www.waagen.lu/datenerfassung/index.html#ethernet-ohaus)
* Lieferprobleme formumlieren: Es soll ein neuer direkter Dialog eingefügt werden, mit Hilfe dessen auf Lieferprobleme eingegangen werden kann
*Wünschenswert wäre aber, dass lediglich die Artikel DIESES Bestellbeleges 73148 angezeigt werden und idealerweise irgendwo auch folgende Infos:
* Bestellung: BBELEG.RID, Bestelldatum: BBELEG.BESTELLT, Lieferant: PERSON.SUCHBEGRIFF
** Der Dialog soll folgende Tasten haben
*** "vergriffen"
*** "+7" Tage
*** "+14" Tage
*** freies Eingabefeld, individuelle Info für den Kunden
*** freies Datumsfeld für den neuen Liefertermin
** passend zur Problem-Nennung sollen eMail VORLAGEN entstehen,
*** ~Tage~, ~LieferDatumNeu~, ~LieferdatumAlt~ soll darin enthalten sein
*** Die Namen der Vorlagen sollen "VERGRIFFEN", "VERZUG" sein
** anhand der Vorlage sollen Kunden eMails zusammengestellt werden (kummuliert). Die Sortierung der Blöcke ist dabei Beleg#,POSNO
** diese sollen zum Zeitpunkt X oder nach 30 Min. versendet werden
** <s>vergriffen
*** im Kunden-Beleg die Zeile suchen
*** MENGE_AUSFALL := MENGE_AUSFALL + MENGE_AGENT, MENGE_AGENT := 0, Daumen
*** im Order-Beleg die Zeile suchen
***  MENGE_AUSFALL := MENGE_AUSFALL + MENGE_ERWARTET, MENGE_ERWARET := 0, Daumen
*** im Artikel
***  PREIS := -1, MINDESTBESTAND := 0</s>
 
=== OrgaMon-App ===
 
* In der Ansicht Liste: Scan eines Lagerplatzes soll als "suche" auf dem richtigen "Auftrag" positionieren
* Neuer Ablauf im Auftrag: "S1" ist bisher Lagerort-Scan, das soll ein GTIN Scan werden
* "Menge" soll berücksichtigt werden, Also 5 Stück -> 5 Scans
* Es soll eigentlich auf dem Gerät 2 Listen geben: Auslagern (bisgher) und neu Einlagern
 
== Beleg ==
 
=== Seitenumbruch-Steuerung ===
 
Ziel: auf einem Seitenumbruch sollten "zusammengehörige" Posten nicht getrennt werden. Zusammengehörigkeit zur vorherigen Zeile könnte durch eine POSNO+1 signalisiert werden. Auch bei der Vertragsanwendung könnte nach einer anwendung (e_w_Merge_Beleg) in POSNO eine Lücke geschrieben werden.
Also sobald die Differenz POSNO[n+1]-POSNO[n]>1 ist, darf das als "Seitenumbruch hier möglich interprätiert werden.
 
http://stackoverflow.com/questions/1664049/can-i-force-a-page-jump-in-html-printing
 
=== Leere letzte Seite vermeiden ===
 
der Seite n-1 sollten Position "gestohlen" werden können. So dass auf der letzten Seite ein "Minimum" an Zeilen ausgegeben wird. Nach dem Maximum soll also auch ein minimum definiert werden können.
 
== Baseupdate ==
 
* Neue Spalte "SQL_NEU" (Text) hier wird das Script für das Update abgelegt.Nun kann man sich selbst auch prüfen, ob ein Update kritisch war oder nicht.
* Neue Spalte "VERMEIDEN" (Boolean) hier wird signalisiert, dass KEIN Update zu dieser Version gemacht werden soll. Damit kann das "Rückwärtige" Update (Rückgängigmachung eines Updates) ausgelöst werden.
* 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 * 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.
 
== 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 ==
 
==="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).<br> -> 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 <br> (-> 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!!!)
 
==Datenbank==
 
* Logik-Log zur Diagnose, dabei lassen sich zu allen Logik-Routinen (ev. organisiert in Gruppen) die Log-Funktion ein oder ausschalten.
* Error-Log zur Speicherung von Fehlerzuständen.
* Kopie auf "Test-System"
* Single-Klick: Generations-Sprung (fdb->fbak->fdb) + .ini Modifikation
* Rückspielen eines DB-Savepoints
 
==System==
 
* SetContext: wenn nicht sichtbar show / wenn nicht gross, auf normal gehen (gross machen)
* Ausgabe von html-Dokumenten:
   @page info (im html!!!) macht auch LibreOffice!!
     http://www.w3.org/TR/REC-CSS2/page.html
     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 Freepascal
**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)
**andere Dienste des Tagesabschlusses, sowie der Tagesabschluss selbst
*** das ist ev. zu schwierig!


todo "Kunden"
* 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.


Kunde: Datum der Probe (niedrige prio) PROBETAG
*Neu: Preise: Es kann nun auch für spätere Ausgabearten ein Preis ermittelt werden.
        Versandtag := Probetag - 2 Versandtage
*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.
  Personen
  Personen – Kontakt muß 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.
  Hinzufügen einer Kundeninfo (Warnmeldung) die hinterlegt wird und beim Aufruf der
  Person in den Vordergrund kommt. Kann nur durch Tastenkombination entfernt werden.
* Christian: 2.Adresszeile für den Kunden, so dass man hier
            "Musikverein "Echo"" eintragen kann. Diese Schreib-
            Hilfe sollte addierend sein! Ev. in den Kunden in ein
            Textfeld übernehmen!
    Alternativ-Adresse angebbar im Beleg (Musikverein a, Musikverein b)


    Die Ankreuzfelder Interessen finden beim Mailingexport verwendung:
==Kunden==
    D.H. das Fenster Mailing wird auch durch die o.g. Felder ergänzt
    (die Felder "Keine Rechnungsempfänger" und "setzen von LetzteÄnderung" können entfallen)
  Interessensgruppen anlegen, Event für diese Interessensgruppe auslösbar
  durch Selektion, ev. Rund-eMail an diese Person.


todo "Belege"
* 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)


    Menge Demoaufnahme ist unendlich, wenn Sound vorhanden
==Belege==
    eMail-Knopf für Sound von Artikel "A" an Kunde "P"
    menge Probestimme ist unendlich, wenn ..\Probestimme vorhanden.


-> Versand-Nachfrage vor dem Buchen der gelieferten Menge!
* Beleg individuelle Zahlungsarten einführen. Sie sollten vorrang vor der Standard-Zahlungsart im Kunden haben.
rechnung 3 spaltig: Packliste überdenken, Packliste "aus" Übergnagsfach!
* Abschaffung von "AUSGANGSRECHNUNG", Ersatz durch "BUCH"
Packliste: Vergangenheit (gelieferte) NICHT ausgeben!
* Abschaffung von BELEG.RECHNUNGSBETRAG und BELEG.DAVONOFFEN
Übergangsfach: Alles da, alles liefern -> überhaupt ein üfach anlegen?
* Storno bzw. Rechnungskorrektur "minus mengen" SETZT NICHT REC AUF GELIEFERT"
  Kundenbestellung.
* menge AA-Probestimme ist unendlich, wenn ..\Probestimme vorhanden.
  Bei der Anlage einer Neubestellung kommt ein Dialog, der abfrägt wie die Bestellung
* Alexander: Bestellbeleg sollen als Infofeld erhalten, wie genau die Anzahl zusammen
  eingeht (1=Telefon; 2=Fax; 3=e-mail; 4=Brief 5=Anrufbeantworter 6=persönlich). – Ohne
              gestellt ist:
  Eingabe geht es nicht weiter !!!
              [] zur Erreichung des Mindestbestandes
* Christian (30.01.01) : Belege, mwst, ausland: In der Endversion nicht aus den
              [] zur Befriedigung von Kundenbestellungen
                          Augen verlieren, daß Auslands-Händler kunden ein bestimmtes
              [] frei aufaddierte/verminderte Anzahl
                          Flag bekommen dass sie Rechnungen ohne MwSt erhalten dürfen!
              ==========
              [] tatsächliche Bestellmenge


todo "Artikel"
==Artikel==


* Bestandshistorie für einzelne Artikel - ev. in ein Memo-Feld!
* Bestandshistorie für einzelne Artikel - ev. in ein Memo-Feld!
* Artikel suche + Selektion
* Artikel: neues Feld "Kapitel", danach auch selektion
* Artikel Neuanlage und Änderung im Beleg-Fenster möglich
* MINDESTBESTAND = Null sollte die blöde "-1" Logik erstetzen. Also Null sollte die Funktionalität von -1 erhalten. Null sollte also einfach "nicht kontrolliert" bedeuten.
* Artikel: neues Feld "Kapitel", danach auch selektion
* GEWICHT = Null sollte die blöde "-1" Logik ersetzen. Also Null sollte einfach "unbekannt" sein
* Neu: Redesign der Artikel-Ansicht
* evalle Worte "VERLAGE" durch MARKEN ersetzten
  Wunsch: neues Artikel-Eingabe Formular!
* nochmals trennen zwischen LIEFERANT und "MARKEN"/"HERSTELLER"
          Anlage, Änderung, Selektion!
  Alexander (18.01.01) : Artikelfeld: Ansicht: Ist es möglich die Ansicht als Formular zu
  gestalten ? Folgende Felder ergeben Drop down Felder bzw. Auswahlfelder
  Komponist, Arrangeur,
  Verlag (siehe Personen/Lieferanten)
  Serie (neu zu gestaltende Tabelle mit RID und Text)
  Gattung (neu zu gestaltende Tabelle mit RID und Text)
  Wunsch: Auch bei den Personen soll das so sein,
          also eine Tabelle, unten ist die Sucheingabe,
          drückt man bei einer Person auf <ENTER>, so öffnet sihc
          das zentrale Eingabe-Formular mit allen Feldern.
          Auch wieder Anlage, Änderung Selektion erfolgt hierüber
          Ausgabe in eine Report-Ausgabe, html, Wordexportmöglichkeit!
  Pakete: Die richtige Lösung ist eine PAKET Tabelle alles andere ist Quatsch! Siehe
        GATTUNG / Kategorie ..


todo "Sonstiges"
==Sonstiges==


* Zusage-Farben auch bei den Gesamtbelegen
* einfacher Wechsel zwischen offenen Fenstern anhand einer Tastenkombination
* Prüfen: (07.03.2002) Übergangsfach wird belegt, obwohl ein Beleg völlig
          versandfertig ist. Es könnte als eigentlich alles direkt in die Kiste!
* Prüfen: (07.03.2002) Übergangsfach wird zu früh freigegeben. -> Das kommt durch
          das zu frühe drücken von "Buchen" das muss in Zukunft der versand machen!
* (09.07.01) unnötige TEXT-PAssagen aus den Artikeln entfernen
    MWST,  = 0, 7 und 16
    VERLAG
* Neu: (05.09.00) rechter Mausklick auf eine Position: auch alle "Stimmen"
                  zeigen: dann auswählen, vor den Titel nun schreiben
                  1. Trompete: <Titel>
                  Preis unverändert lassen
* im Beleg sortieren nach MwSt-Gruppe erst 7 / dann 16
* Bug (13.09.00) : Suchhistorie sollte vor der erneuten Suche automatisch
                    geleert werden.
* Neu (27.09.00) : Such editis (Artikel+Kunden) in den jeweiligen Forms selbst.
* Neu (27.09.00) : Treffer-Liste soll eine Selektion der IB_Query werden -> also
                    Auswahl und Bearbeitung selbst in der Query.
* Info: 4 lange Texte beim Artikel Ü - haben folgende Bedeutung
    BEM = Bemerkung
    Ü1 = Über das Stück
    Ü2 = Üder den Composer
    Ü3 = Über den Arranger
  alles Korrekt in Datenfelder abbilden
* Das Rechnungsempfänger Flag ev. automatisiert setzten, hierzu Situationen suchen!
* Neu (10.11.00) System für Buchungs Alarme:
                  [Meldungstext] [betroffener Beleg_R]
                  [betroffener Kunde_R]
                  [betroffene Beleg-Zeile_R]
                  [betroffener Artikel_R]
                  [erzeugt am(Datum,Uhr)]
                  [reaktion(Art)]
                  [reaktion am(Datum,Uhr)]
                  [bearbeitet durch(Bearbeiter)]
* Suche nach Text in den HTML Ablage-Dateien
* einfacher Wechsel zwischen offenen Fenstern anhand einer Tastenkombination
* Neu: Beleg suche: Einfach wie bei den Personen irgendwas eingeben:
                    * Belegnummer,
                    * German Parcel ID,
                    * DM - Endbetrag,
                    * Namen des "Auftraggebers",
                      "Rechnungempfänger",
                      "Lieferempfänger"


todo "LAGER", "Übergangsfach"
==Lager==


* "A" Taste für jeden Lagerplatz
* "A" Taste für einen Lagerplatz
* "B" Taste für jeden Übergangsfach-Lagerplatz
* "B" Taste für einen Übergangsfach-Lagerplatz
* Warenbewegungshistorie für einen Lagerplatz
* Warenbewegungshistorie für einen Lagerplatz


-> umstellen: "VERLAG_R" im Artikel muss auch wirklich auf die Verlage zeigen!
-> umstellen: "VERLAG_R" im Artikel muss auch wirklich auf die Verlage zeigen!
-> Thema "freies Lager"
-> Thema "freies Lager"
-> Thema "ShowRoom"
-> Thema "ShowRoom"
-> Thema "Verlags Volumen"=2, also Stücke, die 2 Fächer in anspruch nehmen.
-> Thema "Verlags Volumen"=2, also Stücke die 2 Fächer in anspruch nehmen.
-> Thema
-> Thema


  Kommissionierliste für Übergangsfächer erstellen. (Nach Wareneingang
*Kommissionierliste für Übergangsfächer erstellen.  
  bzw. bei Bestellungseingang, wenn noch keine Lieferung erfolgt !)
(Nach Wareneingang bzw. bei Bestellungseingang, wenn noch keine Lieferung erfolgt !)


  Rechnung
*Rechnung
  Die Lieferung erfolgt mit .....
Die Lieferung erfolgt mit .....


  Kundenauftrag
*Kundenauftrag
  automatisierte Information an den Kunden, wenn am Tag der Bestellung keine Lieferung an
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.
  den Kunden rausgeht (Auftragsbestätigung) und zwar per e-mail oder fax.


  Verlagsstatistik
*Verlagsstatistik
  monatliche Verkaufsstatistik der verkauften Artikel eines Verlages. (Soll dem Verlag)
monatliche Verkaufsstatistik der verkauften Artikel eines Verlages. (Soll dem Verlag) per e-mail zur Verfügung gestellt werden)
  per e-mail zur Verfügung gestellt werden)




  *  ev. Prüfen wie "alt" ein Übergangsfach ist. Art Verfallsdatum, das
*  ev. Prüfen wie "alt" ein Übergangsfach ist. Art Verfallsdatum, das warnt, wenn es erreicht ist. ev. zusage auch im Übergangsfach=Verfalssdatum.<br>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).
      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össten 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:
   LISTE der belegten Übergangsfächer:
Zeile 163: Zeile 267:
   LAGER_R IS NOT NULL
   LAGER_R IS NOT NULL


  Zuteilungsmoment ist im Moment nicht bestimmbar. Es gibt aber im eCommerce nur
Zuteilungsmoment ist im Moment nicht bestimmbar. Es gibt aber im eCommerce nur 2 zentrale Punkte für "Eintrag" und Release!
  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.
 
==Konten==
 
* Gesamtbetrag ziehen aus einzelnen Forderungen (ev. Überweisungsplanung, mit Gesamtüberweisung auf einen Schwung jedoch viel text im Buchungstext?!)
* Rechnungseingangsmoment ist der Wareneingang
* Bug: Auftragsverminderung sollte richtig funktionieren! Einfach das richtige machen, wenn bei einem Auftrag eine Auftrags-Menge verändert wird. z.B. rückliefern - bestellung vermindern! - in die Storno-Menge übernehmen ... (usw).
 
==WebShop==
 
=== Entwickler / Tester ===
 
* jeder sollte seine Texteingaben mit "seiner" Farbe versehen. Dies erfolgt durch die Klammerung mit dem span-Tag.
 
<span style="color:#6666AA;">rot</span><br>
<span style="color:#FF0000;">blau</span><br>
<span style="color:#009933;">grün</span><br>
 
=== TPicUpload ===
 
* <s>mal nach Delphi 2010 portieren</s>


  * "räuberische Übernahme": Artikel im Übergangsfach eines anderen zur r.Ü.
==Musikverlag==
    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.


todo "Q-Management", "Caretaker"
* eMail im Versand Moment
* Beleg->suche unten->Anzeige eines Suchtreffers: erste Kategorie (aber letzter Begriff) soll nach dem Titel angezeigt werden.
* im BASIC Druckprozessor: PREIS(ARTIKEL_R) soll normale Preisermittlung rufen.
* neuer Preis-Status "nicht über diesen Verlag lieferbar", FREMD_R (also wirklicher Lieferant sollte angebbar sein!)
* Bestellregel sollte editierbar sein.
* wenn minimized, dann sollte setContext das gross machen.
* ev. Anleitung, um die letzte Rechnung zurückbuchen!
* "gelb" sollte den Status "Ändern" durchgängig symbolisieren, die markierung bei der Artikelsuche ist so komisch gelb


* gewisse Zustände gehen ein in die Q-Zahl.
==Resourcemanagement==
* Die neutrale Froderung ist 100% (besser>100, schlechter<100)
 
* Es gibt Q-Rubriken, diese bilden die Gesatm Q mit gewisser Gewichtung
=== Neuer Status "FallBack" ===
* Jede Q-Komponenete sollte anklickbar (und lösbar sein)
 
* überfällige Mahnungen,
Wenn Monteure einen Termin ohne jegliche Eingaben einfach verstreichen lassen, so wird er vom JonDa Gerät gezogen und auf dem OrgaMon Arbeitsplatz ist dieser Termin unter dem neuen Status "Fall Back" sichtbar.
* überfällige Zusagen
 
* Zwang zur einer De-Escalationsmassnahme ist absolut notwendig, ev.
=== Neuer Status "Flight Control" ===
  sollte das System stoppen und "Top 5" Massnahmen müssen ergriffen
  werden.


todo "Belege"
Das sind Termine in Warte-Stellung (Verschiedene Ursachen ...)
"FlightControl" -> Termin ist auf dem Monteurs-Handy.


  3) Bestellungsbeleg aus dem Knopf "bestellen" erzeugen können.
=== Auftrag neu ===
    Wege sind email und drucker (Fax-Lösung)
* (08.06.01) Alexander "Bestellsystem"
  Alexander (18.01.01) : Bestellsystem:
    Neu (09.11.00) Bestellung aufgrund (Textfeld mit Schreibhilfe) noch hinzufügen!
                    Addierende Schreibhilfe ev. aus SIEMENS Projekt.
    Neu (10.11.00) Belege: <erst liefern ab Datum>
    Neu (10.11.00) Belege: <spätestens liefern bis Datum>
    Neu (10.11.00) Belege: Teillieferungsvereibarung, aber mit einer Wartezeit (out-delay)
                            abhängig von der bisherigen Wartezeit, wenn kein Lieferdatum angegeben.
                            zusammenhalten von kurz hintereinander gelieferten Artikel. Berechnung
                            einer Regel, wie lange auf die Lieferung weiterer Artikel gewartet
                            wird.
    Neu (10.11.00) Belege: pro Position noch Datum:Bestellt am
                            pro Position noch Datum:Erwartet am
  (08.06.01 Alexander) 5. Überwachungsagent Lieferungen für Kunden
  -> Bestell-System:
  voraussichtliches Eintreffdatum für Bestellungen ist von großem Interesse.
  Da ein Event erzeugt werden sollte, wenn ein Beleg einer "Nachforschung"
  bedarf. Eine Kundeninfo sollte dann raus! Ev. kann man hier durch einen einfach
  Massname nach diesem Datum sortieren und dadurch eine große übersichtlichkeit
  erwirken.
  # Bestellung aufgrund: "Neu", mit Ausgabe auf dem (Wie, und wer hat den beleg erstellt)
    Bearbeiter. erste 3 Buchstaben als Kürzel auf die rechnung.
    Wie bestellt ist nur internes feld. (Ev. Benutzerverwaltung aus GaZMa)
  # Zu jedem Beleg. interne Info-Text Editor. (immer sichtbar) erste Zeile sichtbar.
    Belegfenster
* (06.09.01) Alexander, tel. Besprechung
  Bestellung (Kreditoren)
  Eine Änderung der Bestellmenge in dieser Tabelle bzw. Zusammenfassung von gleichen Artikeln
  muss möglich sein. Evtl. mehr bestellte Artikel werden im Falle eines zusätzlichen Kundenauftrages
  gleich diesem Auftrag zugewiesen.
  Auswahlmöglichkeit, ob man diese Position momentan bestellen möchte, oder nicht
  Ein Button "Bestellungen erzeugen" muß eingefügt werden, der alle Titel eines
  Verlages zusammenfasst und gemäß der Eingaben in der Datenbank "Lieferanten" —
  auf dem Weg "E-Mail, Fax, oder postalisch" (nach diese Priorität) versendet. Danach
  wird Protokolldruck gestartet, damit man sieht was er gemacht hat.


* Alexander: Bestellbeleg sollen als Infofeld erhalten, wie genau die Anzahl zusammen
Im Terminarbeitsplatz einfach "Neuanlage" ermöglichen!
              gestellt ist:
              [] zur Erreichung des Mindestbestandes
              [] zur Befriedigung von Kundenbestellungen
              [] frei aufaddierte/verminderte Anzahl
              ==========
              [] tatsächliche Bestellmenge
* (05.07.01) Alexander "PreisCodes->Preistabellen"
  Kreditoren / Artikel / Kunden
  Über Hersteller (E-Verlag) läuft auch die Selektion der Einkaufsquellen! Hierzu erfolgt
  der link auf die Händler-Tabelle (Hersteller implizieren bevorzugte Einkaugsquellen!)
  # Hersteller ist das Feld auf der CD,
    Es gibt auch nur noch dieses Feld, Es dient als Grundlage zur Findung des
    VK-Preises. Preistabellen ev. mit unterschiedlichen Preis-Tabellen.
    Preistabelle:
    Code | Ausprägung | Währung | Preis
    Code = Preiscode
    Ausprägung = Einzelstimme, Partitur, Direktion usw.
    Währung = DEM, EUR
  (05.07.01 Alexander) "Erschienen bei (Ursprungsverlag)->Einkaufsquellen"
  Das Feld Verlag bleibt weiterhin als einzigstes Lieferanten-Informationsfeld
  beim Artikel erhalten. Die Information, bei welchem Lieferanten unter welcher
  Bedingung bestellt wird, wird bei der Kartei "Lieferanten eingepflegt. In einer
  Unterkartei "Bestellbedingungen" Wird z.B. Beim Verlag "Scherzando" bzw.
  "Schott" eingegeben:


[  (Bestellmenge = Gesamtbestellmenge aller möglichen - bei diesem Lieferanten zu
=== Restanten (Geo) ===
  bestellenden Artikel)
  Scherzando
  Prio I Lieferant: I Bestellmenge von bis I Gültig für (Tabelle Artikel Sortiment) I
  -----*--------------+---------+------------------------------------------------------+
    1 I De Haske I 1 I 999999 I Blasorchester, Kammermusik, Tonträger I
  Schott
  Prio I Lieferant: I Bestellmenge von bis I Gültig für (Tabelle Artikel Sortiment) I
  -----+--------------+---------+------------------------------------------------------+
    3 I Halbig I 1 I 4 I , Kammermusik, I
    2 I Schott I 5 I 999999 I , Kammermusik, I
    1 I Schott I 1 I 999999 I Blasorchester, , Tonträger I
    Da Schott gleichzeitig Verlag und Lieferant sein kann, und der auch am schnellsten und
    mit dem höchsten Rabatt liefert, muß hier noch eine Regel eingebaut werden, und zwar
    wenn eine Bestellung bei einem Lieferanten mit niedriger Prio (Halbig) auftritt, aber
    gleichzeitig bei dem Lieferanten Schott (Prio 1) bestellt werden muß, daß alles beim
    Lieferanten Schott bestellt wird.
    Nach diesen Kriterien wird eine Bestelltabelle generiert (Belege Bestellung), bei der
    die errechneten Ergebnisse aber editierbar bleiben (Bestellmenge, Lieferant). In der
    Liste muß es auch die Möglichkeit geben, Artikel momentan nicht zu bestellen (Ankreuzfeld)
  ]
  Diese Logik wir (übergangsweise wie folgt geändert:
  Bei Verlage wird eine neue Spalte hinzugefügt, welche die Einkaufsquelle der
  ersten Priorität enthält (RID)


todo "Konto-Führung"
Hintergrund: Überlegen und Konzept zusammenstellen wie es laufen könnte, dass auch Restanten geolokalisiert in das Tagewerk eingemischt werden. Also wie kann man den Monteuren bei der Auffindung von Restanten helfen. cool!!
=== Restanten (Monteure) ===


* Idee von Christian -> Zahlung: Teilzahlungen, die zu Teillieferungen passen -> weglassen!
Hintergrund: Wie kann man die Monteure besser helfen ihre Restanten im Überblick zu haben? Eine Liste? Soll man Restanten abzeichnen müssen? Wie kann auch JonDa verbessert werden.
  (30.01.01) Christian "Konto-Führung"
   
  2.) Bsp.: ein Kunde bekommt mehrere verschiedene Rechnungen (verschiedene
=== Die perfekte Umterminierung ===
  Belege) und bezahlt bsp.weise drei Rechnungen zusammen (z.B. je DM 100,-,
  zusammen DM 300,-)
  Wenn ich als Zahlungseingang DM 300,- buchen möchte, kommt der Warnhinweis,
  dass das Programm diesen Zahlungseingang keinem Beleg zuweisen kann.
  Es wäre aber wichtig, den Zahlungsvorgang möglichst genau (original)
  nachverfolgen zu können, weswegen ich ungern 3x DM 100,- buchen möchte.
  Fällt Dir eine Lösung ein?
  Christian (30.01.01) 3.) Der Rechnungsbetrag beträgt: DM 490,-. Als Summe sind
  aber nur DM 479,- vermerkt. Der Fehler wird sicherlich durch uns verursacht ("Briefumschlag
  drücken").
  Eine manuelle Änderung der DM 479,- in DM 490,- ist möglich. Als Vorschlag
  für den Zahlungseingang werden auch DM 490,- angegeben.
  Allerdings hat der Kunde laut Konto DM 11,- zuviel bezahlt. Es kommt
  allerdings kein Warnhinweis; es erscheint lediglich bei Saldo eine grün
  hinterlegte -11,00 DM.
  Ist das schlimm, oder kann ich da manuell was ändern?
  Neu: Bei Teillieferungen wird der jeweilige Einzel-Betrag in die
        Buchführung hineingebucht. Es können in Zukunft auch Teil-
        zahlungen akzeptiert werden. Es können Gutschriften und
        Überzahlungen (Zuzahlung Kontoausgleich usw.) gebucht werden.
  * Idee: Ankreuzfeld vollausgleich im
    Konto-Fenster des Kunden, wenn angekreuzt kein erscheinen mehr auf
    Kontoinformatrion über fällige Zahlungen. Vollausgleichskreuz, könnte man
    automatisch setzen?!


* Bei Artikel preis/gewicht-änderung in den posten PREIS,GEWICHT mit ändern
Hintergrund: Beim Umterminieren zusammen mit dem Kunden am Telefon muss man Fuchs und Hase sein! Hier sollte mal ein Dokument erstellt werden, wie die perfekte Umterminierung auszusehen hat. Alles - aber auch wirkliche alle Tricks und Kniffe - sollte hier erfasst werden, so nach dem Motto; 35 Schritte zum perfekten Umterminieren, oder 12 Sachen, die man beim Umterminieren beachten muss. Haben wir das Dokument könnte man was programmieren das Schritt für Schritt diese Checkliste automatisch prüft.
  bei (MENGE_AGENT>0) OR (MENGE_RECHNUNG>0)
* beleg: nach typ/medium angabe gleich status gelb buchen!
* Bestellbeleg: Zusage ermitteln anhand neuem Feld im Verlag: Lieferzeit.
  -> Durchschnittlicher Lieferzeit in Tagen, errechnet sich aus allen
      bisherigen Lieferungen dieses
  -> extreme Ausreiser nicht / wenig berücksichtigen.
  -> maximale Standardabweichung, d.h. ein untypischer Wert wird nur z.B.
      zu 20% gewichtet.
  -> 6 Monate, durchschnitt neu berechnen
* pdf erweitern mit mp3, Kunden muss ankreuzfeld aktiviert haben. Wenn OK,
  Artikelnummer-0*.mp3 darf gemailt werden.
* Beleg: Benutzerverwaltung mit 2 stelligem Kürzel. Start mit beleg-eintrag


Bug: Auftragsverminderung sollte richtig funktionieren! Einfach das richtige
=== nur noch 2 Bemerkungsspalten für Bemerkungen! ===
      machen, wenn bei einem Auftrag eine Auftrags-Menge verändert wird.
      z.B. rückliefern - bestellung vermindern! - in die Storno-Menge übernehmen
      ... (usw).


todo "ep - roll out"
vorlage XLS entsprechend Ändern, dann Kunde um Rückmeldung bitten!!


Bug: Zahlungen: Anzeige von Zahlungen OHNE Belegreferenz gelingt nicht!
Büro Bemerkungen|V1+V2+V3+I3*i4*i5
      Nachträgliches Zuordnen von Zahlungen zu einem Beleg! es kam vor, dass
      Zahlungen keinem Beleg zugeordnet waren.
Bug: Tier: fehlerhaftes Datum in der Liste


// Schwerpunkt "Person"
=== Meldung ===
Neu: Personen Löschen auf Knopfdruck. Auflösung der ganzen Referenzen.
      Im Zusammenhang mit "Personen verschmelzen" lösen! Also so lösen:
      -> Wer übernimmt die Belege?


// allgemein
neues Flag einführen im Auftrags-Datensatz: "mache eine Historischen Datensatz" vor der nächsten Änderung. Also ein "ERHALTUNG" Feld. Dieses Feld muss gesetzt werden, sobald EXPORT_TAN von Null auf irgendwas geändert wird.
Neu: Halter/Tier Volltextsuche, so wie früher
Neu: VERLAGNO -> GOT
Neu: Hauptmenü: Suche nach Betrag


// Tier
=== Leistungsprotokoll ===
Neu: erstes Tier auf der Hauptseite zeigen,
Neu: erstes Tier (neues Feld),


// Belege
Ankreuz/Eingabefelder (Protokoll) für die Monteure, was an diesem Termin alles gemacht wurde!
Neu: Belege: Preiskorrektur auf, Preiskorrektur um +/- %


todo "die zukunft ist linux"
=== Bekannte Fehler ===


  * verschiedene Dienste brauchen eigentlich auch verschiedene Instanzen einer
Nach Modifikationen in der Geräte-Nummer funktioniert das "senden" nicht richtig. Hier überlebt scheinbar ein altes caching-Objekt.
    Anwendung. Sonst blockiert der pdf-Mailer die Verfügbarkeit des xml-rpc usw.
    Also Alexander, so, wie der OrgaMon im Moment programmiert ist, sollte es so
    getrennt bleiben (pdf MESSE, xml BILL). Schön getrennt sind schon folgende
    Dienste:


  - apache (24h)
=== Alte Anforderungen ===
  - php (24h)
  - TWebShop (24h)


  * Langfristig Ich will folgende Dienste ganz ohne Schnickschnack als reine
Neu: Baustellen Shortcuts lassen sich abspeichern.
    eCommerce-Module umprogrammieren (die könnten dann später auch unter linux
Neu: Korrektur-Modus, gefundene Zeile ersetzen
    laufen) Im Moment sind sie fest ins OrgaMon eincompiliert:
Neu: Rückgängig-Funktion
xx: (Keiber) Ansicht von "Name 2" in der Liste ermöglichen (ev. einschaltbar!)
    auf Terminliste ist nun auch Name2 sichtbar (falls belegt).
xx: Import: Frage: wie soll mit doppelten Zählernummern verfahren werden:
    2) hinzuimportieren (fehlt noch)
    es soll in die Historie hinzuimportiert werden.
    doppelte Zählernummern: ev in eine laufende Historie hinzukopieren, aktuellen
    Datensatz bei allen Datenfelder (Palnq. Strasse Ort,) so lassen, aber status
    wieder auf unterminiert. (Nicht angeschreiben, und nkicht Monteur informiert).
    überschreiben , hier mal eine neues Systemaktik erarbeiten.
xx: Besprechung für den Tagesabschluss: verschiedene Buchungen
    * Termin ist abgeschlossen
    * Wiedervorlage
    * Löschungen
    * Fitness Buchungen werten Sperren aus
    * Historie Funktion
      Recherche sollte in "Ablage" DB möglich sein! Ev. über den Status "gelöscht"
      noch klären.
      Ev. hier eine neue (Ablage)Tabelle anlegen?
xx: (Schulung 28.06.01) ausgesprochene Aktualisieren-Taste für die Termin-Liste!
xx: Rückgängig-Taste bei "Monteur-Info" buchen. (Ev. allgemeine Rückgängig Taste
    (sehr schwierig, ev. über ein allg. Datenbank Modul, ev. nur änderungen am
      Auftrag.)
xx: überlegen, wie man Rückläufer markieren kann, so dass sie nicht im
    Tagesabschluss in die Historie-Tabelle verschwinden!
xx: Orsteile-Ansicht:
    "str"
    "plz ort"
    "Ortsteil"
    ev. zur "Ortsteil" Ansicht, eine andere Spalte einsparen, z:b. muss
    "Nummer" nicht so groß ein.
    ev. alle Zeilen etwas höher.
xx: bei einer Zähler-Sperren-Verletzung nicht verplanbar machen! Den Datensatz
    dann völlig leer lassen (im BeforePost!)
xx: Anzeige der Urlaube von den einzelnen Monteuren. Mischung aus Anwesenheit,
    Auslastung. Belegungsliste. als html.
    Monteurliste wie angegeben, mit der Möglichkeit Urlaub, Freizeit und
    Krankheit einzutragen


  - xml-rpc dienst (24h)
! OrgaMon Rev. X.000
    * 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
x: Erzeugung einer Index.html für das Serven im IntraNet!
    * mal forschen, wie läuft das unter kylix
* Berechnung: Baustelle Maximalauslastung pro Monteur, über verfügbare Anzahler der
  - indexerstellung für die Artikel und Personensuche
              Monteure Ergebnis= mit dieser Anzahl an Monteuren
    * das modul entsprechen kylix fähig machen (das ist ev. der erste schritt!)
              (unter Berücksichtigung was schon verplant oder erledigt ist)
  - andere Dienste des Tagesabschlusses, sowie der Tagesabschluss selbst
              wie lange bis Baustelle komplett abgearbeitet. Neuer Funktionsknopf.
    * das ist ev. zu schwierig!
x: In einer späteren Ausbaustufe sollen Rückmeldungen (Erfolgreiche Durchführung)
    der Monteure in das Programm eingetragen werden. Die Monteure sollen mit MDE Geräten
    ausgestattet werden. Per DFÜ werden hochaktuelle Auftragsdaten aus OrgaMon auf
    das MDE übertragen - im Gegenzug sollen Zählerstände, sowie Zähler-Nummern
    rückübertragen werden.
    Ev. sollen die Geräte mit Beleg-Label-Druckern ausgestattet werden. Zur
    Anbringung auf den Zähler.
x:Q: Wenn ein Briefadressat über 16 Zähler informiert wird? Zähler-Standort,
      Zähler-Nummer hierbei aufnehmen.
  A: in Zukunft lösen! Dies im Auge behalten!
x:Baustelle.DateSource.Onsatechange -> hier auch die Farbe auf
  datalink.color ändern! (weis nicht wie das geht!)
x: Verletzung einer Zähler-Sperre ist überhaupt völlig unmöglich, ev. dies
    gar nicht zulassen!


  * der defekt eines Dienstes darf dabei den anderen Dienst nicht mit in den
to-do Bereich
    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 erfüllen
    während OrgaMon weiter dem Benutzer zur Verfügung steht. Dazu könnte man
    einen OrgaMon-Agent erfinden, der auf Befehle des OrgaMon laufert...
  * Massnahmen für schnelleres "Server Hopping": Der Störungsfall BILL hat
    gezeigt, dass eine Rekonstruktion schnell möglich ist. Man muss aber schon an
    sehr vielen Schrauben drehen, so dass ich mir langfristig Vereinfachungen
    wünsche. Den ISAPI Dienst will ich wegkürzen (HebuWeb.dll)!


  * In der Mahnung die Artikel aufführen
* Prüfung aller Sperren auf korrekte Eingabe
  Neu: Import: Warnung, wenn Zählernummern verschiedene Stellenanzahl haben.
* 549 gelöscht
  544 importieren...
  seitenumbruchproblem, also mitten in einer Tabelle, zumindest wenn er eine Zelle
  nicht zerstört. hebuadmin, anzahl der Zeilen
* zusammenziehen von identischen adressen, bzw. identische AB-Nummern
  ev. beim Durchnummerieren selbst merken, wenn "Anschrift" gleich ist (<>Liegenschaft).
  gleich austragsnummer. !!!STRASSE ist dabei gleich!!!
  halbtageweises Sperren ermöglichen
* Feiertage in den jeweiligen Bundesländern berücksichtigen, dabei die Baustelle
  einem Bundesland zuordnen.
* "Minormodifikations-User", "Risky-Modifikation-User" je nach entscheidung ob eine
  Historie eingetragen werden soll oder nicht soll dieser User dauerhaft gespeichert
  werden.
* Strassenverzeichnis informativ: Name aller Strassen, Alpha, PQ, Häufigkeit.
  auf identität bei unterschiedlichem PQ aufmerksam machen.
* Import: nach dazwischenmischen selbst neu durchnummerieren
* Terminarbeitsplatz: Nach Umterminierung und Neuanlage: Warnung Ermittlung aller
  Termine in diesem PQ, Liste aller Termine, Warnung, wenn anderer Termin wie bisher, V/N
  Unterscheidung.
* <ESC> nach Selektion der Baustelle ermöglichen, -> Lange Aktionen sollten ab-
  gebrochen werden können.
* Eingabesperren bzw. Warnungen wenn Sperren oder Auslastung erschöpft ist.
  (Lokaler Check!)
* Warnung, wenn Auslastung pro Baustelle pro Tag von "0" auf "1" wechselt.
  (Er ist gar nicht da fehler!)
* Neuer Parameter: Zeitspanne für "Monteur auf Baustelle"
* Idee: "Alternativ-Termin"-Assistent, Auftrag lokalisiert: nun alternativen aufzeigen!
  (super, ohne weiteres Machbar, z.B. wann sind wir noch in diesem PQ, auf dieser
  Baustelle, wann geht es von der Auslastung her, usw....)
* Zähleraufträge an der selben Stelle zusammenhalten, Auslastung umstellen auf einen
  "Arbeitseinheiten Wert". In der baustelle ev. die Auslastung der Monteure vorgebbar machen
  z.B. Freitag nachmittag = 50%.
* Termine an Samstagen und Sonntagen ermöglichen!
* OutFit für InterNet-Ausgabe anpassen. Rückläufer auch mit Symbol versehen,
  den Index neu aufbauen!
* MVVM, es gibt 4 "doppelte", diese sind aber !leer! wie soll man die dann finden?
* Tagesabschluss, liste aller baustellen, die als Ortsteil-Code '??' eingetragen haben.
Bug: Status angeschrieben, da sind manchmal auch "Monteur informierte" dabei
* "Monteur_informiert" bei Korrektur
* vier mal importiert, die doppelten wurden nicht erkannt!!
* Korrekturfeld: Monteur-Info/Zähler-Info (noch mehr textfelder!)
Bug: Aufträge wurden doppelt auf das Gerät übertragen!
----
* erster Import "absoluter Reihen" für immer so halten (auch Hausnummernreihenfolge so lassen)
* zweiter Import prinzipielle Reihenfolge immer noch beibehalten (bei gefundener Strasse
  versuchen zwischen die Hausnummern zu mischen, jedoch wiederum neue PQs vergeben!)
----
Neu: neue Tabelle
      ARBEITSZEIT.MONTEUR_R, // optinal, Monteur-Urlaub
      ARBEITSZEIT.BAUSTELLE_R, // optional, ganze Baustelle zu/auf?
      ARBEITSZEIT.DATUM
      ARBEITSZEIT.V
      ARBEITSZEIT.N
      ARBEITSZEIT.INFO


todo "aktuell"
      -> Hemmnisse, Urlaub, Feiertage werden hier eingetragen.
      -> Samstag, Sonntag-Arbeit kann hier eingetragen werden.
Auftrags-Zeilen indiduelle "%" Lösung: Angabe der Anzahl der termin, danach
      errechnung eines Prozentsatzes, dann beim Planen eingabe (zuordnen) dieses
      Wertes. Dann kann individuell die Monteurlast (in %) berechnet werden. Auch
      auf schwierige oder einfache Aufträge kann eingegangen werden. Auch z.B. auf
      eine Anfahrt kann eingegangen werden.


* suche nach "verlagno".
      Vormittags / Nachmittags -Angabe: 45% / 70%
  * wer hat welchen Artikel bestellt. Also im Artikel eine Warenbewegngs-historie
  Neu: Turbo-Auslastung:
  für diesen Artikel.
  Erfüllungs-Check:
  * Die Stornierung funktioniert noch nicht perfekt (seit der letzten Rev. bucht
  =========================
  er nur noch mengenmässig, nicht mehr betragsmässig.
  Neu:
* Bei manchen Bestellbelegen ändert sich nach einem gebuchten Wareneingang die
    ANFORDERUNG.BESCHREIBUNG
  Menge nicht von ERW nach GEL ???
    ANFORDERUNG.SOLL
* Im Agent sollte zusätzlich das Preisfeld sichtbar sein !
    ANFORDERUNG.STUECKPREIS
  Frage: Sollten wir nicht den Preisschlüssel in ein echtes Feld übernehmen ?
    ANFORDERUNG.BAUSTELLE_R
  Wir haben ja immernoch das Ziel, die Artikeltabelle neu zu designen bzw. die
  diversen Felder zurückzunehmen.
  * Die Aktionen müssen -wie telefonisch besprochen- mit der WERBE= Logik erweitert werden.
  * Thema CD-Aufnahmen richtig klären!
  Könnte man die CD-Aufnahme - Angabe gleich wie folgt anzeigen:
  Alexander hat sein OK zu Deinem Vorschlag gegeben.
  Kannst Dir mal überlegen, wie der Suchstring aussehen soll, den ich Dir übergebe.
* eMailadressen in Tabelle anlegen. Dabei eindeutigen Index verwenden, der doppelte Einträge
  verhindert. Beim Kunde ist dann das pwd gespeichert.


* Bestätigungsmails an Kunden: Wenn eine Bestellung gesendet wurde, sollte an
    LEISTUNG.BEARBEITER_R
  die e-mail Adresse des Kunden eine Bestätigung über den Erhalt dieser Bestellung
    LEISTUNG.MONTEUR_R
  gesendet werden ! Zusagefeld ist hier ganz wichtig !!! Der genaue Versandbetrag
    LEISTUNG.ANFORDERUNG_R
  muss ausgegeben werden.
    LEISTUNG.IST
* Nach Fakturierung im OrgaMon sollte der Besteller eine e-mail mit dem entsprechenden
    LEISTUNG.DATUM
  html bekommen. (Herr Knam hat heute fakturiert)
  ev. Relaxx-integrieren!
* Nach Versand im OrgaMon sollte der Besteller eine e-Mail mit den versendeten
  erste Schritte zur verbesserten Resource-Planung:
  Artikel bekommen, und was nachgeliefert wird. (Frau Buss hat heute zum versenden
  ---
  bereitgestellt. Link: was bedeutet das genau)
  * -> AA bei der Sortiment-Statistik mitbetrachten!
  * -> Artikel aus Beleg löschen
  * -> Artikel "-" rausnehmen! Oder Nachfrage!
* agent->Wareneingang gesamt->neuer Schalter "alles OK"
* Zusage Feld: alles mal durchspielen! ev. Tagesabschluss einbeziehen!


- 27.08.03
* Status Möglichkeiten mal dokumentieren. Wie "denkt" hier OrgaMon, was ist falsch was kann noch intelligenter gelöst werden.
  * Artikel: ausgewählte Kategorien direkt in der Artikelansicht anzeigen
* Ausgabe der Monteur-Info nach Baustellen sortiert.
  * Beleg: Artikel ohne Kategorie farblich irgendwie anders anzeigen oder Meldunk oder Symbole
* Meldung an Versorger direkt als Excel-Dokument
    K? G?
* Eingabe doppelter Zählernummern "NEU" auf JonDa Verhindern, in OrgaMon Prüfmöglichkeiten zur verfügung stellen.


  * Mahnung: Kunden-Liste erweitern um Namen , Strasse, Ort
=== in Arbeit ===
  * Beleg: Zahlungsweise speichern: "LV; Kreditkarte" in Betrieb nehmen,
    auch wiederum in der html-Vorlage bei Zahlungsweise keine festen Texte, sondern


    "Wird am <Datum> von Konto Kno, BLZ BLZ abgebucht"
[in Arbeit: Neu: Geo: Besondere Farbe für den zuletzt geplanten Punkt.]
    "Wird Ihrer Kreditkarte belastet"
[in Arbeit: Neu: Auftrag: Direkter Sprung vom Auftrag in den Geoarbeitsplatz.]
[in Arbeit: Neu: Shop: Skins, Neuer, total abgespeckter "Skin", Englisch
            + andere farben, kein Login,anderes Bestell System.
[in Arbeit: Neu: Sortierung der Import Möglichkeiten!]
[in Arbeit: Neu: könnten Sie bitte eine Warnmeldung bringen lassen, wenn bei
  Adressen ohne PQ terminiert wird. Es ist uns des öfteren passiert, dass die
  Adressen bei den PQ vergeben wurde nicht ausreichend waren und versehentlich
  weiter terminiert wurde (dann kommen ja die Adressen alphabetisch). ]
[in Arbeit: Neu: Kann man in Zukunft irgendwas einrichten, dass sobald PQ
  eingetragen wird, auch AB-Nr. vergeben wird (auch bei manuellem Eintrag der Planquadrate). ]
[in Arbeit: Neu: Auftrag: Neuordnung der csv!]


  * Belege: Bei Zahlunsweise <> "normal" wird Zahlungsweise Inidividuell eine
==IT-Freiberufler==
    Tabelle geführt, die über die zu buchenden Zahlungen informiert. Ev.
    automatisiert buchen, bzw, die Buchungen Zeile für Zeile bestätigen lassen.
    Zahlungsweise -> Zahlungstexte
  * Beobachtung: Im webshop pdfs geordert, danach kam ne Mail, dass die eMail noch
    nicht bekannt ist, wie kann das sein. Den konkreten Fall bitte konkret
    nachvollziehen, der pdf-Mailer macht inzwischen klasse log-Files. Bitte hier
    mit mir zusammenarbeiten ...


  -- 28.08.03
* Budget sollte Kontingent heissen!<br>
* Zeiterfassung: Ein Kontingent sollte via "Text" wählbar machen!<br>
* Zeiterfassung: Einfach wie bei Thorsten "nächster" Schritt Knopf machen, also es sollte klar sein, dass "Zeit Ende" gebucht werden soll<br>


  * texte sammeln,
[[IT-Freiberufler]]
    -> einzelne unterdrücken,
  * Sachbearbeiter hinterlegen
  * Kammermusik


  Artikel Log - verzeichnen der Bewegungen (Lagerplatz,Üfach,Artikel)
==Landschaftsplege==


  Mindestbesand 2 - nicht mehr "fett". Wenn eine Vermischung zwischen Motivation, besteht
* Belege: Formsize and Position Saver, 2 moveable Splitter, maximizeable!
  dann muss kundenmotvation vorang haben.
* Bestellungen: html vorlagen stimmen?
  ------------------------------------------------
  *
Bug: Versand: 2. Teillieferung muss
Kann man die Bestellung ev. auch als html.Anlage der Bestätigungsmail angehängt werden?


Druck: Grafiken auszugeben, labels mal testen (reine Fontlösung dürfte kein Problem sein)
==Schlosserei==


todo "Buchhaltung"
* Berechnungen über verschiedene Berechnungsarten<br>
* kleine Änderungen im Artikelstamm<br>
* Übernahme von TEILE/ARTIKEL usw.<br>


"Bender" ist ein Buchungsroboter, der entweder im Hintergrund eine Buchungsregel abarbeitet,
oder mit Hilfe von konfigurierbaren Eingabe-Dialogen Buchungsgrundlagen sammelt, um im
Anschluss eine umfassende Buchung durchzuführen. Durch ein Satz von Assistenten hilft
Bender beim Auffinden von Belegen und Personen und Artikeln.
Einzelne Felder haben auswahl-Hilfslisten, die kontextgerecht vorbelegt werden. z.B.
offene Forderungen aus Belegen des Kunden "x". Oder offene Forderungen aus Belegen
mit der Planungszahlungsart "Kreditkarte".


+BENDER (BuchungsRegelwerk, Buchungsmotor, Buchungsvorlage)
== OrgaMon-App ==
  Bezeichnung
  "VK ohne Umsatzsteuer"
  "VK Schulen"  "VK Händler Ausland"
  "VK mit USTID
  "VK ohne USTID
  "VK gewerblich"
  "BZ Kreditkarte"
    VK = Verkaufsvorgang
    BZ = Bezahlvorgang
  Zahlungsart - Lastschrift
  Standard-Zahlungsart - Überweisung


  //
* Neuanschreiben als Status weglassen
  Nummernkreis (nächste Nummer, die Vergeben wird)
* HTTP Request Header
** pragma: IMEI=123456789012345


  // für die "Masken"
=== Idendität Foto ===
  Feldreihenfolge
  Feld Unterdrücken JA/NEIN
  Feldvorbelegung


Bender kann alle Informationen sammeln, und danach eine Geisterbuchung durchführen,
==== Unberechtigte Bilder in Ausstehende Fotos ====
dabei können TestInformationen gesammelt werden. z.B. Existenz aller Konten, anzahl
der Teilbuchungsschritte, salden VOR und NACH der Buchung. Berührte Salen, berührte
Konten usw. Ist alles OK, kann entgültig gebucht werden. Die noch nicht durchgeführten
Buchungen stehen in der ...


  KLADDE
* dass vor allem FT und FK von dem Fehler betroffen waren lag daran, dass diese damit verbundenen Aufträge - obwohl ein erstes Bild schnell gemacht wurde, noch sehr lange "offen" blieb. Also die Aufträge sind wie konserviert, im Protokoll bleiben ja die "FK=..." kleben, er muss immer wieder schauen. Die laufen über viele Tage immer wieder durchs System, das Bild ist schon lange da - da kommt es dabei immer wieder auf die Liste der zu Suchenden, irgendwann ist die wirkliche Bildlieferung so lange her, dass die sich aus dem Sichtfenster wegbewegt hat. Die Bildlieferung wird unsichtbar -> es kommt zum status "ausstehendes" Bild.
  alle Daten, die Bender zur Buchung gesammelt hat. (Im Mittelalter war die Kladde
  eine Zettelsammlung auf der Chronologisch Buchungsvorgänge / Geschäftsvorgänge
  afgezeichnet wurden. Erst in einem 2. Schritt wurde auf andere Bücher übertragen)
  //
  ev. ist die Informationssammlung so komplex, dass es nicht in ein Feld Kostüm
  gepresst werden kann. Ev. muss Bender einen Programm-Text generieren und als
  ein einzelnes TEXT Feld in die Kladde schreiben. Beim Buchen wird dann dieses
  (Mini)Programm ausgeführt und nach Erfolg als gebucht markiert.
  Wie schon im Mittelalter werden Einträge aus der Kladde nicht gelöscht.
  6.1.2004: Neue Idee: Nimmt man die Kladde als einzigste Dateninstanz an, alle
  anderen Konten sind nur Interpretations-Filter der Kladde. Die Kladde enthält
  also alles Wissen um Verteiling von Beträgen ... (Eine Stornierung oder Betrags
  änderung setzt sich somit sofort in allen Konten durch)


PERSONEN
==Geolokalisierung==
  Zahlungsform: +VK Buchung: VK_BENDER_R
  (Bender Standard-Regel die bei Taste Beleg.Neu in den Beleg eingetragen wird.
    Beispiel ist. "Händler&Ausländer&keine USTID". Beim Breifumschalg wird dann
    die entsprechende Regel durchgeführt)
  Zahlungsform: +BZ Buchung: BZ_BENDER_R
  (Regel für den Standard Zahlungseingang. z.B. via Lastschrift)


BELEGE
* gelb soll NICHT berührbar sein
  +PlanAUsgleichszahlung: BZ_BENDER_R
* Pausierte sollen mit einer neuen Farbe sichtbar sein, aber nicht berührbar!
* Unmögliche / Erfolg ev. mit auf der Karte?!
* Terminvorschau, ev. Status Abfragen auf einen zulünftigen Termin ausweiten!


+KONTO (Kontenliste)
==Buchhaltung==
  Nummer
  "8400"
  Bezeichnung
  "Bilanzkonto"
  "Verkauf"
  "Verbrauch"
  "Rabatt"
  "Ums 7%"
  "Ums 16%" "
  "Skonto"
  Art
  Debitoren, Kreditoren, Artikel, Sachkonto


BUCH (das Buch an sich, alle Buchungen)
* Zahlungsbedingungen für Lieferanten (2. ZAHLUNG_R)
* HBCI: Sammelüberweisung
* Ist PERSON_R gesetzt, sollte __PERSONkurz in den Überweisungstext übernommen werden


  // vom system verwaltet
* Migration der Ausgangsrechung nach Buch
  KONTO_R (Konto Referenz, NOT NULL)
* Migration der Beleg-Kopf Fehler nach Buch
  Transaktionsrahmennummer (gleich für die ganze Transaktion)
  BEARBEITER_R


  // benutzereingaben
Vorgehensweise: <br>
  Typ ( Debitor, Kreditor, Sachkonto )
* ALLE "AUSGANGSRECHNUNGEN" Buchungen werden nach BUCH verschoben, zuvor jedoch durch die Angaben aus der BELEG-Referenz ergänzt!
  Text
* BELEG.RECHNUNG/FAELLIG/MAHNUNG/MAHNUNG1/MAHNUNG2/MAHNUNG3/MAHNBESCHEID/RECHNUNGS_BETRAG/DAVON_BEZAHLT/MAHNSTUFE/MAHNUNG/MAHNUNG_AUSGESETZT werden gelöscht!
  Datum
* Das Mahnsystem muss dann überarbeitet werden.
  Dokumentdatum
  Belegnummer
  SollMonitär
  HabenMonitär
  Buchungsart
  Kostenstelle
  Abteilung
  Kostenträger
  SollMenge
  HabenMenge


  // Quer-Informationen
==Mailing==
  Artikel_r
  Beleg_r
  versandbeleg_r (wegen der Teillieferung)
  person_r
  sortiment_r
  posten_r
  bbeleg_r
  bposten_r


(noch keine Lösung für Kontenrahmen-design)
* aus OLAP+Vorlagen.html eine Eventliste für mails erstellen
  * Sachposten: ganzer Buchlungslauf eines Transaktionsrahmen einer Kladde
und die Bodies automatisch füllen //     
  * Bender ist das Regelwerk, dass Einträge in die Kladde generiert.
Mal .html nehmen, jedoch rein auf Textbasis arbeiten
  * Das Hauptmenü wird einen "Bender-Konfigurationsknopf" und eine
Ev. als Quelle selbst wieder ein Email-Ereignis nehmen!
    "Bender-Ausführungsknopf" haben. Man kann also Kladdenbefüllung manuell
Im Body IMMER die Schlangen lassen, oder?
    starten.
Ev. dies nur in der Vorlage machen! Später wird der Aufgeblasene Volltext
  * Stornierungen: Durch eine echte SOLL-Seite / HABEN-Seite der T Konten sind
verwendet.
    Stornierungen gut möglich und visuell auch gut sichtbar. z.B.
* eMail-ID! nachtragen  (ev. neues Feld! ev. Sendebestätigung verarbeiten!)
* ev. in den Systemtexten einen Vorlagen-Text für verschiedene System
Events einpfelgen (Event: "Technische Störung 1" oder so)


    "Forderungen"
==I18n==


    S          H
Im Moment nichts!
    107,00
    -27,00
              80,88
              -0,88


    Geschichte:
==SQL==
    * Der Beleg wurde zu 107 verschickt.
    * Eine berechtigte Rücksendung verursachte eine negative Storno-Buchung
      auf der linken Seite.
    * Es erfolgt die Zahlung des Kunden von 80,00 Euro. Durch einen Tipfehler
      wurde 80,88 Euro gebucht - Viel später wurde das erkannt und -0,88 gebucht.
  * Überzahlungen des Kunden gehen auf ein "Guthaben" Konto, da sie frei in der
    Luft schweben, und keinem beleg zugeordnet werden können. Von diesem Konto,
    kann dann wiederum zum Zahlen von Belege zugegriffen werden.


  * Daneben gibt es festverdrahtet Momente im Innern des orgamon wo Bender
Folgende Generatoren überdenken:
    Regeln automatisch angestossen werden:


  Dies sind im Moment die folgenden Situationen:
GEN_ARRAYS_ID
  ================================
GEN_GEO
GEN_CSV
GEN_JONDA
NK_KUNDE


  * Briefumschlag "Beleg buchen"
==amerikanischer Kunde==
  * Zahlung buchen (im Moment in AUSGANGSRECHNUNGEN - wird ganz neu gestaltet)
  * Warenbewegung, insbesondere Wareneingang insbesondere wenn eine EingangsRechnung vorliegt sowie die entsprechende Bestellung im Orgamon gespeichert ist.


todo "Datenbank-Metadata"
=== Mahnung ===


WARENKORB.ARTIKEL_R not null machen!
pro Beleg nur eine Zeile mit allen kumulierten Werten dieses Vorganges. Für offen, in Verzug, Anzahlung, usw. immer nur ein Summenfeld angeben.
WARENKORB.PERSON_R not null machen!
  * Storno bzw. Rechnungskorrektur "minus mengen" SETZT NICHT REC AUF GELIEFERT"
  * Bug: Anzahlung wird bei "neu" nicht berücksichtigt.


    -<Anzahlungsbeträge> bei "den" überzahlten Belegen
kleine tabelle als Zusammenfassung im unteren Bereich der Mahnung:
    +Anzahlungsbetrag bei dem aktuellen Beleg
  *
  * ich habe mir überlegt, dass Buchungen im Ausgangsrechnungs-Konto OHNE zuordnung
    zu einem Beleg - keinen Sinn machen. Die Sache mit einer rumhängenden Überzahlung
    muss ich mir aber noch überlegen ...


  * Neu: Microsaldobildung belegbezogen: Es darf in Zukunft keine Differenzen zwischen
OFFEN SEIT # SUMME <br>
        einem einzelnen Beleg und seinen Buchungen im Konto Ausgangsrechnunge geben. Im
0-30 Tage | 0,0 €<br>
        Moment mache ich eine Gesamt-Saldo-Differenzbildung, das werde ich noch verfeinern.
31-60 Tage | 200,00 €<br>
  * Neu: Wie von Christian gefordert muss eine Gesamtzahlung des Kunden auf verschiedene
61-90 Tage | 30,00 €<br>
        Belege verteilt werden können
  * RECHNUNGSBETRAG / DAVON Bezahlt sollte abgeschafft werden!


  Neu: Agent: Alle Kreuzchen setzen!
=== Prorata ===
  Neu: Ausdruck Event bei "Warenbewegung" Neueintrag


todo "Thorsten" (wichtige oben)
Ich habe die Prorata informationen eingetragen.
Die Berechnung soll folgendermassen ablaufen:


  * Anmeldung, erste eMail gleich mit einem Link auf die Passwort-Vergabe und
Die Verkaufspreise OHNE Rabatt * Bezahlte Mengen.
    Änderungsmaske.
  * TWebShop sollte nicht mehr lokal gespeichert sein sondern in einem Sub-Dir
    des OrgaMon, und zwar .\shop. Damit kann jeder (im Netz) mal schnell Updates
    einspielen, den Shop pflegen, und verändern. Er geht dann jede Nacht auch mit
    in die Sicherung. (weitere Vorteile: Logfiles sind sichtbar, Install kann jeder
    machen, Ausfallserver kann jeder mit apache installiert spielen ...)
  * TWebShop: alle Bildreferenzen mit einem prefix versehen (Einstellbarer
    Parameter), der entweder leer, sein kann (= lokale referenz) oder eben mit
    'http://raib.de/0815' auf externe Files umlegen:
  * \Sess sollte auch umgezogen werden, und zwar nach .\shop\admin\Sess, damit
    ist sogar eine Session nach umstellen/Lastballancing des Servers noch gültig.
  * Andreas sollte PDF-Pfad prüfen, oder noch besser: Im Rahmen des Tagesabschlusses
    für jeden Artikel selbst prüfen.


todo "Super-Server"
# Mengen die verkauft wurden aber noch nicht bezahlt sollen nicht berücksichtigt werden.
# Preise werden nicht wie bei uns netto also abzüglich der Rabatte berechnet, sondern es wird der Listenpreis gezogen.


  * USA-Provider 1&1 ist im Moment in USA ansässig! Hier einen Vertrag
==Keepcon==
    abschliessen.


  erledigt:
* wget anstelle des ftp und patch der htmls aus dem routeip-project vollständig übernehmen)
  =========
* automatisches Fail - Over auf ISDN (hab ich mir wegen der Verbindungs-Kosten ISDN noch nicht getraut.)
* Es sollte eine Haltbarkeitsdauer von Fail-Over Verbindungen angebbar sein. Damit kann sichergestellt werden, dass keine zu hohen Kosten von Fail-Over Verbindungen entstehen obwohl die Hauptverbindung wieder OK ist.
* Bei einer Neuanwahl einer Verbindung könnte eigentlich die aktuelle firewall geladen bleiben. Man kann auch deaktivierte (oder (noch) nicht vorhandene) Interfaces in einer firewall angeben.
* critical "sites" sollten angebbar sein!
* Bei Fail -> providerwechsel, im neuen provider auch fail -> fallback auf den main-Provider -> PANIC
* critical "ftp" sollten angebbar sein!
* !!!trafic mass controll!!! via "ifconfig" mit dem entsprechenden interface. Also ein Datenbank Eintrag wieviel Daten über die jeweiligen Interfaces geflossen sind.
* Zwangstrennung avoid. Nach 2/3 der Verbindungszeit (und Stille)könnte ein freiwilliges Trennen erfolgen, sobald keepcon keinen aktuellen traffic innerhalb eines gewissen Zeitraumes detectiert. Dieser reconnect ist in der Regel weniger schmerzlich als der im vollen Last-Betrieb.
* Freiwillige Trennung z.B. zwischen 2 und 3 Uhr (einmalig) bei ruhigem traffic! Dies könnte eine Zwandtrennung innerhalb der Geschäftszeiten verhindern!
* Kann man das NAT/MASC Modul fragen, wieviele offene Verbindungen es gibt? Ev. lsof.
* Alive-Check-Konzept: (wget (=httpget) dazu notwendig) In eine Liste lassen sich http anfragen angeben, die Test-Cases starten und normiert "Erfolg" oder eine "Fehlermeldung" liefern.
* im ip-down (z.B. ausgelößt durch eine Zwangstrennung) ein Signal an keepcon schicken, damit weitere Schritte (z.B. erneute anwahl) ausgeführt werden können. Wie kann man jedoch elegant eine Interprozesskommunikation programmieren, die durch ein Script schon verwendbar ist?
* einen hhtp-Server intgerieren der über den aktuellen Status Auskunft gibt. Ev. auch die Konfiguration über diesen Server ermöglichen.


  * SuSe Linux 9.0
==HTML-Vorlagen==
  * DNS, WINS, SMTP-Gateway
  * firebird 1.5 CS Release
  * Apache 2er Reihe
  * PHP 5er
  * TWebShop


  offen:
=== ON/OFF Konzept, optionale Fragmente ===
  ======


   * Samba 3er Reihe
Konzept der "Optionalen Fragmente", entweder Ankreuzbar oder
   * and-firewall (NEU mit funktionierendem Netz, differenzierte Policy, OUTPUT ACCEPT?!)
  eine grundsätzliche Klassifizierung.
      - Auftrag Andre!? -
   S=Single Page
   * keepcon (wget anstelle des ftp und patch der htmls aus dem routeip-project vollständig übernehmen)
   F=First Page (of n)
      - Andreas -
  N=Next Page (of n)
   * XML RPC Kylix
   L=Last Page (of n)
      - Andreas -
   Dokument = S | F [{ N }] L
            |S|F|N|L|
LLLLLLLLL  |X|X| | |  Anschrift
  LLLLLLLL  |X|X| | |  Header
  LLLLLLLL  | | |X|X|  Übertrag
  LLLLLLLL  |X|X|X|X|  Positionen
  LLLLLL    | |X|X| |  Zwischensumme
  LLLLLL    |X| | |X|  Summe


Neu: Mahnung: sich aufhebende Teilzahlungen zu Teillieferungen unterdrücken. Dazu in
=== Variable Consumer ===
              Ausgangsrechnung nun endlich die Spalte TEILLIEFERUNG füllen oder anlegen.
              Beispiel: 4177
Neu: Mahnung: Datumsspalte etwas schmaler machen. Hier wird Platz verschenkt.
              Beispiel: 4177
Neu: Mahnung: Den Saldo eines Beleges in einer eigenen Spalte anzeigen oder am Ende,
              somit eine neue Spalte.
              Beispiel: 2545
Neu: Preise: Es kann nun auch für andere 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.


todo "GaZMa" Integration
// to-do: Block-Consumption angebbar machen, das ist die Anzahl der Zeilen
// oder die aktuelle Höhe, die der eingesetzt Block braucht, im Momnet
// ist das immer "1". Ev. noch prüfen, da er schon korret die <br>
// Zählt.
//


Monteure & Auftraggeber komplett nach Personen integrieren!
=== optimierung "~" ===
Migartions-Hilfe Dialog erstellen und Import testen!


todo "ZE" Integration
// Optimierung des Writevalue, besonders bei grossen Ausbelichtungen:
//
// Bei CheckreplaceOne könnte man einen SuchCache Namens "~" benutzen. Es müssen nicht
// immer alle Zeilen durchsucht werden, sondern die, die ein "~" enthalten. "Stufe 1"
// [Lines]
// Man könnte auch die Stellen (Zeilennummern) verzeichnen wo bestimmte werte noch stehen
// ~XX~ in 0,2,3,4 kommen Zeilen hinzu muss der Cache erweitert werden, finden Ersetzungen statt
// so muss der Cache gekürzt werden. Also eine SearchString@[Lines] Datenstruktur "Stufe 2"
// Immer bei einem Zugang (insert, load, add) könnte man den Cache erweitern


Zeiterfassungsdialog
=== Tabellen ===


  * Preis=0, Preis=auf Anfrage lösen!
  // bei Tabellen besteht das Problem im Moment des letzten Datensatzes oft nicht
  * Preise für Ausgabearten lösen!
// zu wissen, dass es weiter geht. Dann muss im Nachhinein der letzt "load ZEILE MID"
  * VK_Preis bei deim Wareneingang lösen!
// in ein load ZEILE LAST umgesetzt werden. Dies macht diese Routinen
// for n := pred(DatensammlerLokal.count) downto 0 do
// begin
// if (pos(chtml_MIDAUFTRAG, DatensammlerLokal[n]) = 1) then
  // begin
  // DatensammlerLokal[n] := 'load AUFTRAG LAST,AUFTRAG';
// break;
// end;
// end;
//


todo "Frank"
=== EVEN, ODD Verbesserung ===


  * Anzahl als Kommazahl
  // bei Blöcken die even/odd sind, die also eine unterschiedliche ausprägung haben
// abhängig von ihrer Position besteht ein Problem beim sortieren:
// wird die Reihenfolge verändert wird die even/odd eigenschaft belassen, aber
// even kann u.U. nun auf even folgen, was unschön aussieht!
// Die Lösung ist eigentlich ein "$ifpos" Konstruct inerhalb eines Fragmentes
// Die ganze Logik für die Ausprägungsunterschiede müssen also im Fragement selbst
// formuluiert werden können. Es werden dann nicht mehr 2 alternative Blöcke zur
// verfügung gestellt, sondern nur noch einer, aber mit allen möglichen Varianten
// schon per Logikausdrücken in sich drin.

Aktuelle Version vom 23. Januar 2024, 14:13 Uhr

Bugs (bekannte Fehler)

Warenwirtschaft

"offene Order"

Warenannahme

  • soll zunächst aus offene Belege kopiert werden
  • Ablauf
    • Artikel-Scan, Suche in den erwarteten Mengen,
    • Darstellung der ganzen anderen Erwarteten des beleges (Farben verwenden)
    • pro 1 Scan bei erwartete Menge=1: das ist analog zu Drücken von einem [W]
    • sind es mehrere wird gewartet bis alle gescannt sind, danach erst die Buchung
  • Bei der Annahme soll kontrolliert werden
    • GTIN (wie bisher)
    • Artikelbild nachlesen, wird anhand eines Scanners geliefert, Verzeichnis soll konfigurierbar sein, VErzeichnis soll im Hintergrund geprüft werden bis Bild da ist
    • Gewicht nachlesen, wenn leer oder 0, USB Waage soll hier angeschafft werden (http://www.waagen.lu/datenerfassung/index.html#ethernet-ohaus)
  • Lieferprobleme formumlieren: Es soll ein neuer direkter Dialog eingefügt werden, mit Hilfe dessen auf Lieferprobleme eingegangen werden kann
  • Wünschenswert wäre aber, dass lediglich die Artikel DIESES Bestellbeleges 73148 angezeigt werden und idealerweise irgendwo auch folgende Infos:
  • Bestellung: BBELEG.RID, Bestelldatum: BBELEG.BESTELLT, Lieferant: PERSON.SUCHBEGRIFF
    • Der Dialog soll folgende Tasten haben
      • "vergriffen"
      • "+7" Tage
      • "+14" Tage
      • freies Eingabefeld, individuelle Info für den Kunden
      • freies Datumsfeld für den neuen Liefertermin
    • passend zur Problem-Nennung sollen eMail VORLAGEN entstehen,
      • ~Tage~, ~LieferDatumNeu~, ~LieferdatumAlt~ soll darin enthalten sein
      • Die Namen der Vorlagen sollen "VERGRIFFEN", "VERZUG" sein
    • anhand der Vorlage sollen Kunden eMails zusammengestellt werden (kummuliert). Die Sortierung der Blöcke ist dabei Beleg#,POSNO
    • diese sollen zum Zeitpunkt X oder nach 30 Min. versendet werden
    • vergriffen
      • im Kunden-Beleg die Zeile suchen
      • MENGE_AUSFALL := MENGE_AUSFALL + MENGE_AGENT, MENGE_AGENT := 0, Daumen
      • im Order-Beleg die Zeile suchen
      • MENGE_AUSFALL := MENGE_AUSFALL + MENGE_ERWARTET, MENGE_ERWARET := 0, Daumen
      • im Artikel
      • PREIS := -1, MINDESTBESTAND := 0

OrgaMon-App

  • In der Ansicht Liste: Scan eines Lagerplatzes soll als "suche" auf dem richtigen "Auftrag" positionieren
  • Neuer Ablauf im Auftrag: "S1" ist bisher Lagerort-Scan, das soll ein GTIN Scan werden
  • "Menge" soll berücksichtigt werden, Also 5 Stück -> 5 Scans
  • Es soll eigentlich auf dem Gerät 2 Listen geben: Auslagern (bisgher) und neu Einlagern

Beleg

Seitenumbruch-Steuerung

Ziel: auf einem Seitenumbruch sollten "zusammengehörige" Posten nicht getrennt werden. Zusammengehörigkeit zur vorherigen Zeile könnte durch eine POSNO+1 signalisiert werden. Auch bei der Vertragsanwendung könnte nach einer anwendung (e_w_Merge_Beleg) in POSNO eine Lücke geschrieben werden. Also sobald die Differenz POSNO[n+1]-POSNO[n]>1 ist, darf das als "Seitenumbruch hier möglich interprätiert werden.

http://stackoverflow.com/questions/1664049/can-i-force-a-page-jump-in-html-printing

Leere letzte Seite vermeiden

der Seite n-1 sollten Position "gestohlen" werden können. So dass auf der letzten Seite ein "Minimum" an Zeilen ausgegeben wird. Nach dem Maximum soll also auch ein minimum definiert werden können.

Baseupdate

  • Neue Spalte "SQL_NEU" (Text) hier wird das Script für das Update abgelegt.Nun kann man sich selbst auch prüfen, ob ein Update kritisch war oder nicht.
  • Neue Spalte "VERMEIDEN" (Boolean) hier wird signalisiert, dass KEIN Update zu dieser Version gemacht werden soll. Damit kann das "Rückwärtige" Update (Rückgängigmachung eines Updates) ausgelöst werden.
  • 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 * 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.

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

"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!!!)

Datenbank

  • Logik-Log zur Diagnose, dabei lassen sich zu allen Logik-Routinen (ev. organisiert in Gruppen) die Log-Funktion ein oder ausschalten.
  • Error-Log zur Speicherung von Fehlerzuständen.
  • Kopie auf "Test-System"
  • Single-Klick: Generations-Sprung (fdb->fbak->fdb) + .ini Modifikation
  • Rückspielen eines DB-Savepoints

System

  • SetContext: wenn nicht sichtbar show / wenn nicht gross, auf normal gehen (gross machen)
  • Ausgabe von html-Dokumenten:
  @page info (im html!!!) macht auch LibreOffice!!
   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 Freepascal
    • 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)
    • 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.
  • 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
  • MINDESTBESTAND = Null sollte die blöde "-1" Logik erstetzen. Also Null sollte die Funktionalität von -1 erhalten. Null sollte also einfach "nicht kontrolliert" bedeuten.
  • GEWICHT = Null sollte die blöde "-1" Logik ersetzen. Also Null sollte einfach "unbekannt" sein
  • ev. alle Worte "VERLAGE" durch MARKEN ersetzten
  • nochmals trennen zwischen LIEFERANT und "MARKEN"/"HERSTELLER"

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.

Konten

  • Gesamtbetrag ziehen aus einzelnen Forderungen (ev. Überweisungsplanung, mit Gesamtüberweisung auf einen Schwung jedoch viel text im Buchungstext?!)
  • Rechnungseingangsmoment ist der Wareneingang
  • Bug: Auftragsverminderung sollte richtig funktionieren! Einfach das richtige machen, wenn bei einem Auftrag eine Auftrags-Menge verändert wird. z.B. rückliefern - bestellung vermindern! - in die Storno-Menge übernehmen ... (usw).

WebShop

Entwickler / Tester

  • jeder sollte seine Texteingaben mit "seiner" Farbe versehen. Dies erfolgt durch die Klammerung mit dem span-Tag.

rot
blau
grün

TPicUpload

  • mal nach Delphi 2010 portieren

Musikverlag

  • eMail im Versand Moment
  • Beleg->suche unten->Anzeige eines Suchtreffers: erste Kategorie (aber letzter Begriff) soll nach dem Titel angezeigt werden.
  • im BASIC Druckprozessor: PREIS(ARTIKEL_R) soll normale Preisermittlung rufen.
  • neuer Preis-Status "nicht über diesen Verlag lieferbar", FREMD_R (also wirklicher Lieferant sollte angebbar sein!)
  • Bestellregel sollte editierbar sein.
  • wenn minimized, dann sollte setContext das gross machen.
  • ev. Anleitung, um die letzte Rechnung zurückbuchen!
  • "gelb" sollte den Status "Ändern" durchgängig symbolisieren, die markierung bei der Artikelsuche ist so komisch gelb

Resourcemanagement

Neuer Status "FallBack"

Wenn Monteure einen Termin ohne jegliche Eingaben einfach verstreichen lassen, so wird er vom JonDa Gerät gezogen und auf dem OrgaMon Arbeitsplatz ist dieser Termin unter dem neuen Status "Fall Back" sichtbar.

Neuer Status "Flight Control"

Das sind Termine in Warte-Stellung (Verschiedene Ursachen ...) "FlightControl" -> Termin ist auf dem Monteurs-Handy.

Auftrag neu

Im Terminarbeitsplatz einfach "Neuanlage" ermöglichen!

Restanten (Geo)

Hintergrund: Überlegen und Konzept zusammenstellen wie es laufen könnte, dass auch Restanten geolokalisiert in das Tagewerk eingemischt werden. Also wie kann man den Monteuren bei der Auffindung von Restanten helfen. cool!!

Restanten (Monteure)

Hintergrund: Wie kann man die Monteure besser helfen ihre Restanten im Überblick zu haben? Eine Liste? Soll man Restanten abzeichnen müssen? Wie kann auch JonDa verbessert werden.

Die perfekte Umterminierung

Hintergrund: Beim Umterminieren zusammen mit dem Kunden am Telefon muss man Fuchs und Hase sein! Hier sollte mal ein Dokument erstellt werden, wie die perfekte Umterminierung auszusehen hat. Alles - aber auch wirkliche alle Tricks und Kniffe - sollte hier erfasst werden, so nach dem Motto; 35 Schritte zum perfekten Umterminieren, oder 12 Sachen, die man beim Umterminieren beachten muss. Haben wir das Dokument könnte man was programmieren das Schritt für Schritt diese Checkliste automatisch prüft.

nur noch 2 Bemerkungsspalten für Bemerkungen!

vorlage XLS entsprechend Ändern, dann Kunde um Rückmeldung bitten!!

Büro Bemerkungen|V1+V2+V3+I3*i4*i5

Meldung

neues Flag einführen im Auftrags-Datensatz: "mache eine Historischen Datensatz" vor der nächsten Änderung. Also ein "ERHALTUNG" Feld. Dieses Feld muss gesetzt werden, sobald EXPORT_TAN von Null auf irgendwas geändert wird.

Leistungsprotokoll

Ankreuz/Eingabefelder (Protokoll) für die Monteure, was an diesem Termin alles gemacht wurde!

Bekannte Fehler

Nach Modifikationen in der Geräte-Nummer funktioniert das "senden" nicht richtig. Hier überlebt scheinbar ein altes caching-Objekt.

Alte Anforderungen

Neu: Baustellen Shortcuts lassen sich abspeichern.
Neu: Korrektur-Modus, gefundene Zeile ersetzen
Neu: Rückgängig-Funktion
xx: (Keiber) Ansicht von "Name 2" in der Liste ermöglichen (ev. einschaltbar!)
    auf Terminliste ist nun auch Name2 sichtbar (falls belegt).
xx: Import: Frage: wie soll mit doppelten Zählernummern verfahren werden:
    2) hinzuimportieren (fehlt noch)
    es soll in die Historie hinzuimportiert werden.
    doppelte Zählernummern: ev in eine laufende Historie hinzukopieren, aktuellen
    Datensatz bei allen Datenfelder (Palnq. Strasse Ort,) so lassen, aber status
    wieder auf unterminiert. (Nicht angeschreiben, und nkicht Monteur informiert).
    überschreiben , hier mal eine neues Systemaktik erarbeiten.
xx: Besprechung für den Tagesabschluss: verschiedene Buchungen
    * Termin ist abgeschlossen
    * Wiedervorlage
    * Löschungen
    * Fitness Buchungen werten Sperren aus
    * Historie Funktion
      Recherche sollte in "Ablage" DB möglich sein! Ev. über den Status "gelöscht"
      noch klären.
      Ev. hier eine neue (Ablage)Tabelle anlegen?
xx: (Schulung 28.06.01) ausgesprochene Aktualisieren-Taste für die Termin-Liste!
xx: Rückgängig-Taste bei "Monteur-Info" buchen. (Ev. allgemeine Rückgängig Taste
    (sehr schwierig, ev. über ein allg. Datenbank Modul, ev. nur änderungen am
     Auftrag.)
xx: überlegen, wie man Rückläufer markieren kann, so dass sie nicht im
    Tagesabschluss in die Historie-Tabelle verschwinden!
xx: Orsteile-Ansicht:
    "str"
    "plz ort"
    "Ortsteil"
    ev. zur "Ortsteil" Ansicht, eine andere Spalte einsparen, z:b. muss
    "Nummer" nicht so groß ein.
    ev. alle Zeilen etwas höher.
xx: bei einer Zähler-Sperren-Verletzung nicht verplanbar machen! Den Datensatz
    dann völlig leer lassen (im BeforePost!)
xx: Anzeige der Urlaube von den einzelnen Monteuren. Mischung aus Anwesenheit,
    Auslastung. Belegungsliste. als html.
    Monteurliste wie angegeben, mit der Möglichkeit Urlaub, Freizeit und
    Krankheit einzutragen

! OrgaMon Rev. X.000

x: Erzeugung einer Index.html für das Serven im IntraNet!
* Berechnung: Baustelle Maximalauslastung pro Monteur, über verfügbare Anzahler der
              Monteure Ergebnis= mit dieser Anzahl an Monteuren 
              (unter Berücksichtigung was schon verplant oder erledigt ist) 
              wie lange bis Baustelle komplett abgearbeitet. Neuer Funktionsknopf.
x: In einer späteren Ausbaustufe sollen Rückmeldungen (Erfolgreiche Durchführung)
   der Monteure in das Programm eingetragen werden. Die Monteure sollen mit MDE Geräten
   ausgestattet werden. Per DFÜ werden hochaktuelle Auftragsdaten aus OrgaMon auf
   das MDE übertragen - im Gegenzug sollen Zählerstände, sowie Zähler-Nummern
   rückübertragen werden.
   Ev. sollen die Geräte mit Beleg-Label-Druckern ausgestattet werden. Zur
   Anbringung auf den Zähler.
x:Q: Wenn ein Briefadressat über 16 Zähler informiert wird? Zähler-Standort,
     Zähler-Nummer hierbei aufnehmen.
  A: in Zukunft lösen! Dies im Auge behalten!
x:Baustelle.DateSource.Onsatechange -> hier auch die Farbe auf
  datalink.color ändern! (weis nicht wie das geht!)
x: Verletzung einer Zähler-Sperre ist überhaupt völlig unmöglich, ev. dies
   gar nicht zulassen!

to-do Bereich

* Prüfung aller Sperren auf korrekte Eingabe
  Neu: Import: Warnung, wenn Zählernummern verschiedene Stellenanzahl haben.
* 549 gelöscht
  544 importieren...
  seitenumbruchproblem, also mitten in einer Tabelle, zumindest wenn er eine Zelle
  nicht zerstört. hebuadmin, anzahl der Zeilen
* zusammenziehen von identischen adressen, bzw. identische AB-Nummern
  ev. beim Durchnummerieren selbst merken, wenn "Anschrift" gleich ist (<>Liegenschaft).
  gleich austragsnummer. !!!STRASSE ist dabei gleich!!!
  halbtageweises Sperren ermöglichen
* Feiertage in den jeweiligen Bundesländern berücksichtigen, dabei die Baustelle
  einem Bundesland zuordnen.
* "Minormodifikations-User", "Risky-Modifikation-User" je nach entscheidung ob eine
  Historie eingetragen werden soll oder nicht soll dieser User dauerhaft gespeichert
  werden.
* Strassenverzeichnis informativ: Name aller Strassen, Alpha, PQ, Häufigkeit.
  auf identität bei unterschiedlichem PQ aufmerksam machen.
* Import: nach dazwischenmischen selbst neu durchnummerieren
* Terminarbeitsplatz: Nach Umterminierung und Neuanlage: Warnung Ermittlung aller
  Termine in diesem PQ, Liste aller Termine, Warnung, wenn anderer Termin wie bisher, V/N
  Unterscheidung.
* <ESC> nach Selektion der Baustelle ermöglichen, -> Lange Aktionen sollten ab-
  gebrochen werden können.
* Eingabesperren bzw. Warnungen wenn Sperren oder Auslastung erschöpft ist.
  (Lokaler Check!)
* Warnung, wenn Auslastung pro Baustelle pro Tag von "0" auf "1" wechselt.
  (Er ist gar nicht da fehler!)
* Neuer Parameter: Zeitspanne für "Monteur auf Baustelle"
* Idee: "Alternativ-Termin"-Assistent, Auftrag lokalisiert: nun alternativen aufzeigen!
  (super, ohne weiteres Machbar, z.B. wann sind wir noch in diesem PQ, auf dieser
  Baustelle, wann geht es von der Auslastung her, usw....)
* Zähleraufträge an der selben Stelle zusammenhalten, Auslastung umstellen auf einen
  "Arbeitseinheiten Wert". In der baustelle ev. die Auslastung der Monteure vorgebbar machen
  z.B. Freitag nachmittag = 50%.
* Termine an Samstagen und Sonntagen ermöglichen!
* OutFit für InterNet-Ausgabe anpassen. Rückläufer auch mit Symbol versehen,
  den Index neu aufbauen!
* MVVM, es gibt 4 "doppelte", diese sind aber !leer! wie soll man die dann finden?
* Tagesabschluss, liste aller baustellen, die als Ortsteil-Code '??' eingetragen haben.
Bug: Status angeschrieben, da sind manchmal auch "Monteur informierte" dabei
* "Monteur_informiert" bei Korrektur
* vier mal importiert, die doppelten wurden nicht erkannt!!
* Korrekturfeld: Monteur-Info/Zähler-Info (noch mehr textfelder!)
Bug: Aufträge wurden doppelt auf das Gerät übertragen!
----
* erster Import "absoluter Reihen" für immer so halten (auch Hausnummernreihenfolge so lassen)
* zweiter Import prinzipielle Reihenfolge immer noch beibehalten (bei gefundener Strasse
  versuchen zwischen die Hausnummern zu mischen, jedoch wiederum neue PQs vergeben!)
----
Neu: neue Tabelle
     ARBEITSZEIT.MONTEUR_R, // optinal, Monteur-Urlaub
     ARBEITSZEIT.BAUSTELLE_R, // optional, ganze Baustelle zu/auf?
     ARBEITSZEIT.DATUM
     ARBEITSZEIT.V
     ARBEITSZEIT.N
     ARBEITSZEIT.INFO
     -> Hemmnisse, Urlaub, Feiertage werden hier eingetragen.
     -> Samstag, Sonntag-Arbeit kann hier eingetragen werden.
Auftrags-Zeilen indiduelle "%" Lösung: Angabe der Anzahl der termin, danach
     errechnung eines Prozentsatzes, dann beim Planen eingabe (zuordnen) dieses
     Wertes. Dann kann individuell die Monteurlast (in %) berechnet werden. Auch
     auf schwierige oder einfache Aufträge kann eingegangen werden. Auch z.B. auf
     eine Anfahrt kann eingegangen werden.
     Vormittags / Nachmittags -Angabe: 45% / 70%
Neu: Turbo-Auslastung:
Erfüllungs-Check:
=========================
Neu:
    ANFORDERUNG.BESCHREIBUNG
    ANFORDERUNG.SOLL
    ANFORDERUNG.STUECKPREIS
    ANFORDERUNG.BAUSTELLE_R
    LEISTUNG.BEARBEITER_R
    LEISTUNG.MONTEUR_R
    LEISTUNG.ANFORDERUNG_R
    LEISTUNG.IST
    LEISTUNG.DATUM
ev. Relaxx-integrieren!
erste Schritte zur verbesserten Resource-Planung:
---
  • Status Möglichkeiten mal dokumentieren. Wie "denkt" hier OrgaMon, was ist falsch was kann noch intelligenter gelöst werden.
  • Ausgabe der Monteur-Info nach Baustellen sortiert.
  • Meldung an Versorger direkt als Excel-Dokument
  • Eingabe doppelter Zählernummern "NEU" auf JonDa Verhindern, in OrgaMon Prüfmöglichkeiten zur verfügung stellen.

in Arbeit

[in Arbeit: Neu: Geo: Besondere Farbe für den zuletzt geplanten Punkt.]
[in Arbeit: Neu: Auftrag: Direkter Sprung vom Auftrag in den Geoarbeitsplatz.]
[in Arbeit: Neu: Shop: Skins, Neuer, total abgespeckter "Skin", Englisch
            + andere farben, kein Login,anderes Bestell System.
[in Arbeit: Neu: Sortierung der Import Möglichkeiten!]
[in Arbeit: Neu: könnten Sie bitte eine Warnmeldung bringen lassen, wenn bei
  Adressen ohne PQ terminiert wird. Es ist uns des öfteren passiert, dass die
  Adressen bei den PQ vergeben wurde nicht ausreichend waren und versehentlich
  weiter terminiert wurde (dann kommen ja die Adressen alphabetisch). ]
[in Arbeit: Neu: Kann man in Zukunft irgendwas einrichten, dass sobald PQ
 eingetragen wird, auch AB-Nr. vergeben wird (auch bei manuellem Eintrag der Planquadrate). ]
[in Arbeit: Neu: Auftrag: Neuordnung der csv!]

IT-Freiberufler

  • Budget sollte Kontingent heissen!
  • Zeiterfassung: Ein Kontingent sollte via "Text" wählbar machen!
  • Zeiterfassung: Einfach wie bei Thorsten "nächster" Schritt Knopf machen, also es sollte klar sein, dass "Zeit Ende" gebucht werden soll

IT-Freiberufler

Landschaftsplege

  • Belege: Formsize and Position Saver, 2 moveable Splitter, maximizeable!
  • Bestellungen: html vorlagen stimmen?

Schlosserei

  • Berechnungen über verschiedene Berechnungsarten
  • kleine Änderungen im Artikelstamm
  • Übernahme von TEILE/ARTIKEL usw.


OrgaMon-App

  • Neuanschreiben als Status weglassen
  • HTTP Request Header
    • pragma: IMEI=123456789012345

Idendität Foto

Unberechtigte Bilder in Ausstehende Fotos

  • dass vor allem FT und FK von dem Fehler betroffen waren lag daran, dass diese damit verbundenen Aufträge - obwohl ein erstes Bild schnell gemacht wurde, noch sehr lange "offen" blieb. Also die Aufträge sind wie konserviert, im Protokoll bleiben ja die "FK=..." kleben, er muss immer wieder schauen. Die laufen über viele Tage immer wieder durchs System, das Bild ist schon lange da - da kommt es dabei immer wieder auf die Liste der zu Suchenden, irgendwann ist die wirkliche Bildlieferung so lange her, dass die sich aus dem Sichtfenster wegbewegt hat. Die Bildlieferung wird unsichtbar -> es kommt zum status "ausstehendes" Bild.

Geolokalisierung

  • gelb soll NICHT berührbar sein
  • Pausierte sollen mit einer neuen Farbe sichtbar sein, aber nicht berührbar!
  • Unmögliche / Erfolg ev. mit auf der Karte?!
  • Terminvorschau, ev. Status Abfragen auf einen zulünftigen Termin ausweiten!

Buchhaltung

  • Zahlungsbedingungen für Lieferanten (2. ZAHLUNG_R)
  • HBCI: Sammelüberweisung
  • Ist PERSON_R gesetzt, sollte __PERSONkurz in den Überweisungstext übernommen werden
  • Migration der Ausgangsrechung nach Buch
  • Migration der Beleg-Kopf Fehler nach Buch

Vorgehensweise:

  • ALLE "AUSGANGSRECHNUNGEN" Buchungen werden nach BUCH verschoben, zuvor jedoch durch die Angaben aus der BELEG-Referenz ergänzt!
  • BELEG.RECHNUNG/FAELLIG/MAHNUNG/MAHNUNG1/MAHNUNG2/MAHNUNG3/MAHNBESCHEID/RECHNUNGS_BETRAG/DAVON_BEZAHLT/MAHNSTUFE/MAHNUNG/MAHNUNG_AUSGESETZT werden gelöscht!
  • Das Mahnsystem muss dann überarbeitet werden.

Mailing

  • aus OLAP+Vorlagen.html eine Eventliste für mails erstellen

und die Bodies automatisch füllen // Mal .html nehmen, jedoch rein auf Textbasis arbeiten Ev. als Quelle selbst wieder ein Email-Ereignis nehmen! Im Body IMMER die Schlangen lassen, oder? Ev. dies nur in der Vorlage machen! Später wird der Aufgeblasene Volltext verwendet.

  • eMail-ID! nachtragen (ev. neues Feld! ev. Sendebestätigung verarbeiten!)
  • ev. in den Systemtexten einen Vorlagen-Text für verschiedene System

Events einpfelgen (Event: "Technische Störung 1" oder so)

I18n

Im Moment nichts!

SQL

Folgende Generatoren überdenken:

GEN_ARRAYS_ID
GEN_GEO
GEN_CSV
GEN_JONDA
NK_KUNDE

amerikanischer Kunde

Mahnung

pro Beleg nur eine Zeile mit allen kumulierten Werten dieses Vorganges. Für offen, in Verzug, Anzahlung, usw. immer nur ein Summenfeld angeben.

kleine tabelle als Zusammenfassung im unteren Bereich der Mahnung:

OFFEN SEIT # SUMME
0-30 Tage | 0,0 €
31-60 Tage | 200,00 €
61-90 Tage | 30,00 €

Prorata

Ich habe die Prorata informationen eingetragen. Die Berechnung soll folgendermassen ablaufen:

Die Verkaufspreise OHNE Rabatt * Bezahlte Mengen.

  1. Mengen die verkauft wurden aber noch nicht bezahlt sollen nicht berücksichtigt werden.
  2. Preise werden nicht wie bei uns netto also abzüglich der Rabatte berechnet, sondern es wird der Listenpreis gezogen.

Keepcon

  • wget anstelle des ftp und patch der htmls aus dem routeip-project vollständig übernehmen)
  • automatisches Fail - Over auf ISDN (hab ich mir wegen der Verbindungs-Kosten ISDN noch nicht getraut.)
  • Es sollte eine Haltbarkeitsdauer von Fail-Over Verbindungen angebbar sein. Damit kann sichergestellt werden, dass keine zu hohen Kosten von Fail-Over Verbindungen entstehen obwohl die Hauptverbindung wieder OK ist.
  • Bei einer Neuanwahl einer Verbindung könnte eigentlich die aktuelle firewall geladen bleiben. Man kann auch deaktivierte (oder (noch) nicht vorhandene) Interfaces in einer firewall angeben.
  • critical "sites" sollten angebbar sein!
  • Bei Fail -> providerwechsel, im neuen provider auch fail -> fallback auf den main-Provider -> PANIC
  • critical "ftp" sollten angebbar sein!
  • !!!trafic mass controll!!! via "ifconfig" mit dem entsprechenden interface. Also ein Datenbank Eintrag wieviel Daten über die jeweiligen Interfaces geflossen sind.
  • Zwangstrennung avoid. Nach 2/3 der Verbindungszeit (und Stille)könnte ein freiwilliges Trennen erfolgen, sobald keepcon keinen aktuellen traffic innerhalb eines gewissen Zeitraumes detectiert. Dieser reconnect ist in der Regel weniger schmerzlich als der im vollen Last-Betrieb.
  • Freiwillige Trennung z.B. zwischen 2 und 3 Uhr (einmalig) bei ruhigem traffic! Dies könnte eine Zwandtrennung innerhalb der Geschäftszeiten verhindern!
  • Kann man das NAT/MASC Modul fragen, wieviele offene Verbindungen es gibt? Ev. lsof.
  • Alive-Check-Konzept: (wget (=httpget) dazu notwendig) In eine Liste lassen sich http anfragen angeben, die Test-Cases starten und normiert "Erfolg" oder eine "Fehlermeldung" liefern.
  • im ip-down (z.B. ausgelößt durch eine Zwangstrennung) ein Signal an keepcon schicken, damit weitere Schritte (z.B. erneute anwahl) ausgeführt werden können. Wie kann man jedoch elegant eine Interprozesskommunikation programmieren, die durch ein Script schon verwendbar ist?
  • einen hhtp-Server intgerieren der über den aktuellen Status Auskunft gibt. Ev. auch die Konfiguration über diesen Server ermöglichen.

HTML-Vorlagen

ON/OFF Konzept, optionale Fragmente

Konzept der "Optionalen Fragmente", entweder Ankreuzbar oder
 eine grundsätzliche Klassifizierung.
 S=Single Page
 F=First Page (of n)
 N=Next Page (of n)
 L=Last Page (of n)

 Dokument = S | F [{ N }] L

            |S|F|N|L|
LLLLLLLLL   |X|X| | |  Anschrift
  LLLLLLLL  |X|X| | |  Header
  LLLLLLLL  | | |X|X|  Übertrag
  LLLLLLLL  |X|X|X|X|  Positionen
 LLLLLL     | |X|X| |  Zwischensumme
 LLLLLL     |X| | |X|  Summe

Variable Consumer

// to-do: Block-Consumption angebbar machen, das ist die Anzahl der Zeilen
// oder die aktuelle Höhe, die der eingesetzt Block braucht, im Momnet
// ist das immer "1". Ev. noch prüfen, da er schon korret die 
// Zählt. //

optimierung "~"

// Optimierung des Writevalue, besonders bei grossen Ausbelichtungen:
//
// Bei CheckreplaceOne könnte man einen SuchCache Namens "~" benutzen. Es müssen nicht
// immer alle Zeilen durchsucht werden, sondern die, die ein "~" enthalten. "Stufe 1"
// [Lines]
// Man könnte auch die Stellen (Zeilennummern) verzeichnen wo bestimmte werte noch stehen
// ~XX~ in 0,2,3,4 kommen Zeilen hinzu muss der Cache erweitert werden, finden Ersetzungen statt
// so muss der Cache gekürzt werden. Also eine SearchString@[Lines] Datenstruktur "Stufe 2"
// Immer bei einem Zugang (insert, load, add) könnte man den Cache erweitern

Tabellen

// bei Tabellen besteht das Problem im Moment des letzten Datensatzes oft nicht
// zu wissen, dass es weiter geht. Dann muss im Nachhinein der letzt "load ZEILE MID"
// in ein load ZEILE LAST umgesetzt werden. Dies macht diese Routinen
// for n := pred(DatensammlerLokal.count) downto 0 do
// begin
// if (pos(chtml_MIDAUFTRAG, DatensammlerLokal[n]) = 1) then
// begin
// DatensammlerLokal[n] := 'load AUFTRAG LAST,AUFTRAG';
// break;
// end;
// end;
//

EVEN, ODD Verbesserung

// bei Blöcken die even/odd sind, die also eine unterschiedliche ausprägung haben
// abhängig von ihrer Position besteht ein Problem beim sortieren:
// wird die Reihenfolge verändert wird die even/odd eigenschaft belassen, aber
// even kann u.U. nun auf even folgen, was unschön aussieht!
// Die Lösung ist eigentlich ein "$ifpos" Konstruct inerhalb eines Fragmentes
// Die ganze Logik für die Ausprägungsunterschiede müssen also im Fragement selbst
// formuluiert werden können. Es werden dann nicht mehr 2 alternative Blöcke zur
// verfügung gestellt, sondern nur noch einer, aber mit allen möglichen Varianten
// schon per Logikausdrücken in sich drin.