Kundenverwaltung

  • MyMattes schrieb:

    Wie wäre es mit "max"...?

    Mattes
    Danach hab ich schon gesucht gehab aber kein Beispiel dafür gefunden wie es eingesetzt wird um es mir vorstellen zu können.

    Das mit dem count Funktioniert aber was ist wenn, wie schon geschrieben, ein Kunde gelöscht wird?

    Mit meinen Codeschnipsel da oben erhalte ich die zuletzt verwendete Nummer aber ich weiß nun nicht wie ich den Wert um 1 erhöhen kann?

  • matze511 schrieb:

    Danach hab ich schon gesucht gehab aber kein Beispiel dafür gefunden wie es eingesetzt wird um es mir vorstellen zu können.

    Das mit dem count Funktioniert aber was ist wenn, wie schon geschrieben, ein Kunde gelöscht wird?

    Mit meinen Codeschnipsel da oben erhalte ich die zuletzt verwendete Nummer aber ich weiß nun nicht wie ich den Wert um 1 erhöhen kann?
    Du hast das Problem, dass eine Nummer mehrmals vergeben werden kann, sowohl beim Zählen der Einträge als auch bei der Ermittlung des größten Werts. (Egal, ob du das über max oder einen sortierten Fetch machst.)

    Wenn du Duplikate vermeiden willst, musst du die Kundennummern getrennt von den Kunden ermitteln. In einer relatonalen Datenbank würde man dafür in der Regel eine Sequence verwenden, die es auch in SQLite gibt. Allerdings bietet CoreData keinen einfachen Zugriff darauf. Eine andere Möglichkeit ist eine Tabelle, in der du die letzte Kundennummer ablegst. Das lässt sich auch in CoreData abbilden.
    „Meine Komplikation hatte eine Komplikation.“

  • matz schrieb:

    AppleDeveloper schrieb:

    Aber warum willst du denn unbedingt eine fortlaufende Nummer? Wenn du nur Nummern willst dan nimm einfach das Datum und mach ne Zahl drauf. Besonders wenn du Milli Sekunden dürfte es einmalig werden. Nur eben etwas länger aber einmalig.
    Kundenverwaltung
    Wenn man benutzbare Kundennummern haben will, dann sind die UUIDs ein bisschen unpraktisch. Die kann man nicht mal schnell am Telefon durchgeben. Dann lieber den aktuellen Zeitstempel als Hexadezimalzahl.
    „Meine Komplikation hatte eine Komplikation.“

  • macmoonshine schrieb:

    MyMattes schrieb:

    Wie wäre es mit "max"...?
    Kommt auf's gleiche raus, wenn du den neusten Kunden löschst.
    Isses in dem Fall nicht egal, die Nummer einer Karteileiche zu reanimieren?
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • volker schrieb:

    Amin Negm-Awad schrieb:

    torquato schrieb:

    Ich bin von Haus aus Literaturwissenschaftler. Kein Mathematiker. Was weiß ich denn von Nummern und Zahlen? :P
    Ach, daher rührt die Liebe zu Swift. Gedichte kann man damit bestimmt prima schreiben, nur Programme halt nicht.
    Oder halt nicht jeder kann damit Programme schreiben :whistling:
    volker
    *räusper*

    Aber irgendwie ist das ja komisch. Das erinnert an C++: Programmieren als Männlichkeitsbeweis. Dabei war es doch eigentlich der Sinn von höheren Programmiersprachen, das Programmieren zu erleichtern. Sogar von jeder. In gewisser Weise die Existenzberechtigung.

    "Damit kann halt nicht jeder" klingt dann ein bisschen so wie "hat keine Existenzberechtigung".
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Die Frage ist wohl eher aus kaufmännischer denn auf programmiertechnischer Sicht zu beantworten.

    1. Kaufmännische ID (Kundennummer) und 'Daten'-ID für Relationships sind zwei paar Schuhe. Hoffentlich.
    2. Anwender wollen 'Nummernkreise' oft selbst festlegen, z. B. eigene für Debitoren und Kreditoren, Artikel, Rechnungen,...
    3. wo wir bei der Trennung von 'Kontakten' und 'Debitoren'/'Kreditoren' wären
    4. schließlich braucht ein Kontakt, dem ich einen Brief schreibe, keine Kundennummer/Debitorenkonto
    5. was zu folgender Struktur führt:
    a) Kontakt: hier interessiert niemanden eine 'Kundennummer'
    b) Debitor: der braucht eine Kundennummer. Idealerweise ein Mapping zu einem Debitorenkonto oder am besten gleich die Nummer des Debitorenkontos
    c) Kreditor: hier gilt das selbe. Ein Kontenplan hat üblicherweise einen anderen Nummernkreis für Debitoren als für Kreditoren.
    d) jeder hat andere Gewohnheiten bezüglich der Nummernvergabe. Daher benötigt man eine eigene Entity für Nummenrnkreise. Damit kann man auch sehr einfach hochzählen.

    Eine kaufmännische Anwendung ohne kaufmännische Grundkenntnisse zu erstellen, bis hin zur Buchhaltung, halte ich für fahrlässig.

    LG Norbert

  • norbi schrieb:




    Eine kaufmännische Anwendung ohne kaufmännische Grundkenntnisse zu erstellen, bis hin zur Buchhaltung, halte ich für fahrlässig.
    Es soll keine kaufmännische Anwendung werden, da dies nur zur Aufnahme von Details dienen soll, um später ein Angebot zu erstellen, die Kundennummer ist im Moment nur Beiwerk um vlt ein besseres syncen zum Rechner zu machen. Und vlt ganz zum Schluß mal eine Blitzkalkulation gemacht werden kann.

  • Um mal den Thread hier aufzuwärmen, ich halte kein empfohlenes Vorgehen for nützlich, eher für Kontraproduktiv. Aber mal zum Problem:

    Normal löst man dies mit eine separaten Nummernkreis, heist also, Es gibt eine Tabelle NK mit {NK; höchste vergebene Nummer} Auf diesen NK macht man eine Abfrage, dann ein Inkremment und schreibt die höchste Nummer wieder zurück. Die Neue Nummer wird Vergeben, das war es. Wenn man will, vergibt man eine temp Nr, welche später mit der neuen Nummer ersetzt wird. Genau hierfür taugt ein Timestamp zum kommunizieren, aber nicht für mehr als 48 Stunden.

    Was mich jetzt mal, interessehalber interessiert ist, welche Erfahrungen der TO mit dem implenentierten Workaround gesammelt hat?

    Und ja, das FinMa schwrrt sich einen feuchten um die Kdnr ;) Was Ihr wichtig ist ist die verfolgbarkeit der Belege, welche Eindeutig sein muss und auch ohne Lücken...

    Schöne Grüße
    Wolf

  • Wolf schrieb:

    Genau hierfür taugt ein Timestamp zum kommunizieren, aber nicht für mehr als 48 Stunden.
    Timestamps werden in der Regel als Zeiteinheiten von einem Referenzdatum gemessen (z.B. Millisekunden seit 1.1.1970). Sie eignen sich also für beliebige Zeiträume. EOF, viele OR-Mapper und meines Wissens auch CoreData verwenden Timestamps um global eindeutige, temporäre Objekt-Ids zu erzeugen.
    „Meine Komplikation hatte eine Komplikation.“

  • macmoonshine schrieb:

    Wolf schrieb:

    Genau hierfür taugt ein Timestamp zum kommunizieren, aber nicht für mehr als 48 Stunden.
    Timestamps werden in der Regel als Zeiteinheiten von einem Referenzdatum gemessen (z.B. Millisekunden seit 1.1.1970). Sie eignen sich also für beliebige Zeiträume. EOF, viele OR-Mapper und meines Wissens auch CoreData verwenden Timestamps um global eindeutige, temporäre Objekt-Ids zu erzeugen.
    Bei einer millisekundengenauen Auflösung wäre es ein leichtes, ein paar tausend Objekte mit derselben ID zu erzeugen. Das funktioniert nicht. Aber NSUUID hat, IIRC, auch einen Zeitbestandteil.

    Ich habe es mal gemacht, indem ich zwar eine Timestamp genommen habee, mir aber immer den letzten Zeitstempel vermerkte und falls ich denselben bekam, einen Zähler hoch setzte. Das war dann also sozusagen jetzt.0, jetzt.1, jetzt.2, …

    Daneben, auch wenn das nicht unmittelbar mit deiner Lösung zu tun hat, muss ich eine lustige Geschichte erzählen, bei der ein Kunde versuchte, den Zeitstempel so wie man ihn bekommen kann als Fließkommazahl zu speichern. Der beschwerte sich dann arg böse, weil auf einmal ganz viele Objekte denselben Zeitstempel hatten. Es lag daran, dass das Fließkommaformat von CD eine geringere Auflösung hatte.

    "Blödes Core Data" – "Äh, nein, das Wesen von Fließkommazahlen?"
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?