DANKE!!
Knöpfe -> des war vorher wirklich doof. Da muss man sich halt daran gewöhnen. Vllt wären sie rechts ganz schön so wie die Burger auf Touchscreens ;-) Aber das kann ich auch über css selber machen.
Artikel neu -> Ich hatte mir das eben schon angewöhnt und keine doppelten mehr, weil ich das wusste. Jetzt muss ich eben erst die Artikelnummer kopieren bevor ich den neuen anlege. Ich habe aber soeben festgestellt, dass die benutzerdefinierten Variablen nicht mit übernommen werden. Das war vorher aber auch ein Problem. Das hat auch nicht immer geklappt.
Ich meine mich zu erinnern, dass das nur dann ging, wenn der Artikel direkt gespeichert wurde. Mit zwischendrin "erneuern" waren die auch weg. Ich gebe die EAN nämlich immer über einen Handscanner ein und der führte dann zu erneuern. D. h. Ich habe immer erst die neue Nummer eingegeben, dann gespeichert und anschließend die EAN eingegeben. Dann waren die CVARS da. Jetzt weiß ich noch nicht ob die CVARS irgendwie übernommen werden können.
In meinem CMS geht das duplizieren über Smarty mit Rechtsklick -> Duplikat anlegen -> neuen Namen angeben (Vorgabe ist "Duplikat von xxxyyy". Da werden aber wirklich alle Untertabellen mit kopiert.
Freier Preis -> Mit den zigerlei Preisen ist für mich sowieso eher hinderlich als nützlich, da ich nichts herstelle und nur Handelsware habe. D. h. die Unterscheidung zwischen Listenpreis und Einkaufspreis führt für mich nur zu doppeltem Pflegeaufwand. Zumal die Preise nicht mit 3 Nachkommastellen gespeichert werden.
D. h. wenn ich einen neuen Artikel ins Sortiment aufnehme, lege ich einen an, kopiere die verschiedenen Varianten über neu abspeichern mit EAN (s. o.). Anschließend ändere ich dann den Preis über die Wareneditormakse im CRM. Da werden die Preise nämlich mit 3 Stellen gespeichert. Und zwar Einkaufs- und Listenpreis auf den gleichen Wert.
Turnusmäßig gehe ich immer mal wieder alle Artikelgruppen durch und ändere so die Preise, damit ich nicht bei jeder Einkaufsrechnung zigmal klicken muss. Bei jeder Einkaufrechnung, bei der ich nämlich zu einem anderen Preis einkaufe ändert sich der Einkaufspreis und der ist dann wieder 2-stellig.
Mit den Preisfaktoren bin ich nicht klar gekommen. Ich kaufe 10 Stück für 14,65€ netto und verkaufe diese dann einzeln zum Bruttovk von 3,55€. Ich habe nicht rausgefunden wie ich das mit den Preisfaktoren abbilden kann. Daher kaufe ich 10 Stück zum Einzelpreis von 1,465 und das kann ich dann nicht speichern. Ist aber das kleinere Übel als beim Verkauf jedesmal 0,1 als Menge einzugeben, was auch falsch ist und dann falsch auf dem Kassenbon steht.
Die Preise je Lieferant habe ich wieder komplett abgeschafft. Die können nämlich nur manuell gepflegt werden (oder csv) und pfuschen dann jedesmal auch noch in den Rechnungen mit rum. (Abgeschafft heißt ich habe über postgres die Tabellen geleert ;-) )
benutzerspezifische Suchmasken -> Hört sich sehr gut an. Ich weiß, dass das sehr viel Arbeit macht das alte umzustellen.
Ich kenne mich halt weder mit Perl noch mit Latex aus. Und ich gebe offen zu, dass mir das auch zu kompliziert und umständlich ist, für den Nutzen, den ich als Einzelkämpfer daraus hätte, das auch noch zu lernen.
Für mich geht es einfach schneller, eine SQL-Select zu schreiben über Datenbankverbindung direkt in der Calc-Tabelle anzuzeigen und meine Pivot-Tabellen damit zu füllen. Da habe ich alles auf einen Blick. Mit der Methode mache ich auch meine Inventur
- Abfrage nach Artikel über Pivottabelle in Libreoffice-Calc,
- Mit Bluetooth Handscanner alle EAN direkt am Regal einscannen,
- über 3. Tabelle die Differenzen anzeigen lassen,
- über CRM-Lagerkorrektur die Mengen ändern.
Der Betatester macht jetzt mal die Bude zu und geht nach Hause. Morgen teste ich dann weiter und schreibe, was mir noch auffällt.
Tut mir leid, dass ich euch so vollgequatscht habe, aber alternativ hätte ich die Buchhaltung zu machen und das ist ja total mein Hobby.
Schönen sonnigen Abend noch