To do: Unterschied zwischen den Versionen
Root (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
Root (Diskussion | Beiträge) |
||
(170 dazwischenliegende Versionen von 7 Benutzern werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
[[ | [[Bugs|Bugs (bekannte Fehler)]]<br> | ||
== Warenwirtschaft == | |||
=== "offene Order" === | |||
Warenannahme | |||
* <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 === | |||
* ev. Prüfen wie "alt" ein Übergangsfach ist. Art Verfallsdatum, das | 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 | |||
* 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.<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). | |||
LISTE der belegten Übergangsfächer: | LISTE der belegten Übergangsfächer: | ||
Zeile 116: | Zeile 267: | ||
LAGER_R IS NOT NULL | 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. | |||
<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> | |||
==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!<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> | |||
[[IT-Freiberufler]] | |||
==Landschaftsplege== | |||
* Belege: Formsize and Position Saver, 2 moveable Splitter, maximizeable! | |||
* Bestellungen: html vorlagen stimmen? | |||
==Schlosserei== | |||
* Berechnungen über verschiedene Berechnungsarten<br> | |||
* kleine Änderungen im Artikelstamm<br> | |||
* Übernahme von TEILE/ARTIKEL usw.<br> | |||
== 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: <br> | |||
* 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 <br> | |||
0-30 Tage | 0,0 €<br> | |||
31-60 Tage | 200,00 €<br> | |||
61-90 Tage | 30,00 €<br> | |||
=== Prorata === | |||
Ich habe die Prorata informationen eingetragen. | |||
Die Berechnung soll folgendermassen ablaufen: | |||
Die Verkaufspreise OHNE Rabatt * Bezahlte Mengen. | |||
# 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. | |||
==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 <br> | |||
// 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. |
Aktuelle Version vom 23. Januar 2024, 14:13 Uhr
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
- Der Dialog soll folgende Tasten haben
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!
- xml-rpc dienst (24h)
- 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
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.
- 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.
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.