Kundenverwaltung

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Wenn Du die Daten eh in CoreData hast, ist es leicht / schnell, die maximale Kundennummer abzufragen. Sonst merkst Du Dir immer die zuletzt vergebene, vielleicht direkt im iCloud Key-Store, um mehrere Geräte zu unterstützen.

    Denk daran, dass die Nummern nicht lange lückenlos fortlaufend sein werden, wenn ein Kunde mal gelöscht wird.

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.

  • Ist das ein Anfang, woraus man Kundennummern erzeugen kann? Ich hab nach auto-incremented gesucht und bei stackoverflow gefunden.

    C-Quellcode

    1. //
    2. // Create a new entity description
    3. //
    5. NSEntityDescription *entity = [NSEntityDescription entityForName:@"MyEntity" inManagedObjectContext:self.managedObjectContext];
    7. //
    8. // Set the fetch request
    9. //
    11. NSFetchRequest *fetchRequest = [[[NSFetchRequest alloc] init] autorelease];
    12. [fetchRequest setEntity:entity];
    14. //
    15. // We need to figure out how many
    16. // existing groups there are so that
    17. // we can set the proper ID.
    18. //
    19. // To do so, we use an aggregated request.
    20. //
    22. [fetchRequest setResultType:NSDictionaryResultType];
    23. [fetchRequest setPropertiesToFetch:[NSArray arrayWithObject:@"entityID"]];
    25. NSError *error = nil;
    27. NSArray *existingIDs = [self.managedObjectContext executeFetchRequest:fetchRequest error:&error];
    30. if (error != nil) {
    32. //
    33. // TODO: Handle error.
    34. //
    36. NSLog(@"Error: %@", [error localizedDescription]);
    37. }
    39. NSInteger newID = 0;
    41. for (NSDictionary *dict in existingIDs) {
    42. NSInteger IDToCompare = [[dict valueForKey:@"entityID"] integerValue];
    44. if (IDToCompare >= newID) {
    45. newID = IDToCompare + 1;
    46. }
    47. }
    49. //
    50. // Create the actual entity
    51. //
    53. MyEntity *newEntity = [[MyEntity alloc] initWithEntity:entity insertIntoManagedObjectContext:self.managedObjectContext];
    55. //
    56. // Set the ID of the new entity
    57. //
    59. [newEntity setEntityID:[NSNumber numberWithInteger:newID]];
    61. //
    62. // ... More Code ...
    63. //
    Alles anzeigen
    oder sollte ich doch lieber den Tip weiter verfolgen für spätere sachen?

    MyMattes schrieb:

    Wenn Du die Daten eh in CoreData hast, ist es leicht / schnell, die maximale Kundennummer abzufragen. Sonst merkst Du Dir immer die zuletzt vergebene, vielleicht direkt im iCloud Key-Store, um mehrere Geräte zu unterstützen.

    Denk daran, dass die Nummern nicht lange lückenlos fortlaufend sein werden, wenn ein Kunde mal gelöscht wird.

    Mattes

  • Amin Negm-Awad schrieb:

    zakspeed schrieb:

    Ich würde generell keinen Datensatz löschen sondern den Kunden in einem extra Feld auf inaktiv setzen.
    Klaus
    Wieso?
    Änderungen sind dann leichter zu synchronisieren.
    «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

  • Uh. Also. Nein.
    Es gibt kein Auto-Increment weil es keine Primary Keys gibt. Core Data ist keine Datenbank.
    Und lass um Himmels Willen die Finger von entityID. Die darf sich nämlich nur bis zum ersten Speichern verändern und tut das gern auch mal vom System aus, also lass das lieber.
    Ansonsten holst Du Dir unter Umständen Unmengen von Inkosistenzen ins Haus.

    Ein zusammengeschustertes Beispiel:

    C-Quellcode

    1. // Ganz kurios: Wir fangen mal nicht bei 0 sondern bei 10.000 an. Weil es geht.
    2. NSUInteger startingCustomerNumber = 10000;
    4. // Fetch Request über alle Kunden
    5. NSFetchRequest * allCostumersFetchRequest = [NSFetchRequest requestWithEntityName:"@Customer"];
    7. /*
    8. Nur zum Überblick, lässt sich auch zusammenfassen:
    9. Der Fetch Request holt alle gespeicherten Kunden.
    10. (Tendenziell hast Du das in Deiner App eh schon einmal gemacht und hältst dieses Array bereits vor.)
    11. */
    12. NSArray * customers = [self.managedObjectContext executeFetchRequest:fetchRequest error:&error];
    14. // Darauf lassen sich die typischen Array-Funktionen aufrufen.
    15. NSUInteger newCustomerNumber = startingCustomerNumber + [[customers count] integerValue];
    Alles anzeigen


    Was auch immer oben zurückkommt, unten wird übersetzt zu

    C-Quellcode

    1. // Noch nix gefunden, [nil count] == nil, [nil integerValue] == 0;
    2. NSUInteger newCustomerNumber = 10000 + 0;
    3. // 1 Kunde gefunden
    4. NSUInteger newCustomerNumber = 10000 + 1;
    5. // 500 Kunden gefunden
    6. NSUInteger newCustomerNumber = 10000 + 500;


    Obacht! Bei diesem Ansatz ist es hochgradig wichtig, Kunden beizubehalten und inaktiv zu schalten.
    NICHT löschen!

    Sonst hättest Du nach diesem Vorgehen doppelte Kundennummern:

    C-Quellcode

    1. [customers removeObjectAtIndex:123];
    2. // [customers count] == 499
    3. [customers addObject:[[Customer alloc] initWithName:@"ACME"]];
    4. // CustomerNumber 10500 wird zum zweiten mal vergeben.

    Läuft eventuell noch bei Kundennummern, bei Rechnungsnummern findet das Finanzamt das aber überhaupt nicht mehr witzig. ;)
    «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

  • Es geht ganz kurz und dafür richtig:

    Du kannst ohnehin doppelte PK haben, weil bei einer Synchronisation auf zwei verschiedenen Geräten lokal derselbe PK (kurz) vor der Synchronisation vergeben worden sein könnte.

    Merke: PK taugen ohnehin nie zur Synchronisation, werden daher nicht bei Synchronisationen verwendet und irgendeine irgendwie geartete Überlegung, irgendwas mit PK könne irgendwie eine Synchronisation erleichtern, sind im Ansatz fehlerhaft.

    Also noch einmal zurück zum Anfang:

    Amin Negm-Awad schrieb:

    Wieso?

    BTW: Das Finanzamt lässt Nummernkreise zu. Sonst hätte ALDI Süd ein Problem.

    Nummernkreise sind aber keine Lösung für das Problem der kollidierenden PK. Sie sind bestenfalls Frickelei mit Schätztechnik. Die Lösung sind UUID bei der Synchronisation und lokale PK-UUID-Mappings.
    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"?

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Amin Negm-Awad ()

  • Marco Feltmann schrieb:

    Und lass um Himmels Willen die Finger von entityID. Die darf sich nämlich nur bis zum ersten Speichern verändern und tut das gern auch mal vom System aus, also lass das lieber.
    Ich glaube kaum, dass hier diese entityID etwas mit der objectID, die du vermutlich meinst, zu tun hat.

    Marco Feltmann schrieb:

    Obacht! Bei diesem Ansatz ist es hochgradig wichtig, Kunden beizubehalten und inaktiv zu schalten.
    NICHT löschen!
    Hmm, und was machst du, wenn mal ein Kunde zu dir kommt und dich auffordert, alle Daten, die ihn betreffen zu löschen?

  • Amin
    Wenn Du eine Löschung auf einem Server hast und zu blöd bist ein ordentliches API bereitzustellen, frickelst Du am Ende mit dem Abgleich der lokalen mit den entfernten Werten herum und musst händisch sämtliche Änderungen kombinieren. Mit Glück findest Du dann heraus, ob Werte einfach nur nicht übergeben wurden, weil Deine API so beschissen ist, oder ob sie gelöscht wurden.
    Liefert Dein API hingegen den alten Identifier und ein wie auch immer geartetes leeres Objekt zurück weißt Du: Das Ding wurde gelöscht.

    (Meine Antwort bezog sich konkret auf die Frage nach der Generierung einer Zahl als Identifikationsmerkmal auf einem einzelnen Gerät und hat erst mal nix mit dem 'Markieren statt Löschen' Paradigma zu tun.

    Michael
    Stimmt, ich meinte die objectID. Ich bitte die entstandene Verwirrung zu entschuldigen.

    Der Aufforderung zum Löschen komme ich natürlich nach indem ich das Objekt im NSArray durch ein 'GelöschtWeil: Am:' ersetze.
    Eventuell bin ich noch so freundlich ihm den Auszug der über ihn neu gespeicherten Daten zukommen zu lassen.
    Da ich aber Rechnungen gemäß §14b Abs. 1 UStG 10 Jahre aufbewahren muss, klappt das mit dem restlosen Vernichten seiner Daten eh nicht so schnell.
    Gemäß Datenschutzgesetz ist es eigentlich ausreichend, die Daten so zu verändern, dass die Person nicht mehr behelligt wird/werden kann. Das wäre, eine entsprechende Implementierung vorausgesetzt, auch mit einem Inaktivitätsflag gegeben.
    Vor übereifrigen Outbound-Mitarbeitern, die die Rechnungen der letzten zehn Jahre durchgehen um neu zu aquirieren hilft aber auch das harte Löschen aus der Datenbank nicht.
    «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

  • Marco Feltmann schrieb:

    (Meine Antwort bezog sich konkret auf die Frage nach der Generierung einer Zahl als Identifikationsmerkmal auf einem einzelnen Gerät und hat erst mal nix mit dem 'Markieren statt Löschen' Paradigma zu tun.
    Ach, so. Ich hatte nur danach gefragt, warum Markieren statt Löschen besser ist. Da dachte ich halt, deine Antwort habe damit etwas zu tun.

    Übrigens hat das Problem nun gar nichts damit zu tun, wie die API auf deinem Server ist. Aber das nur so am Rande, da es ja ohnehin gar nicht darum ging.
    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"?

  • Also ich bin der Meinung den Kunden, solange es denn nicht zu einer Rechnungslegung kam und Geld geflossen ist, kann ich unproblematisch Löschen und diese Nummer wieder verwenden. Daran sollte sich das Finanzamt keineswegs stören und auch nicht ob da Lückenschluß in den Nummern ist.
    Erst bei den Rechnungsnummern, die dann eh über die ein Rechnungsprogramm etc laufen muß ich dem Finanzamt hieb und stichfest eine fortlaufende Nummer liefern. Und da ist nur noch Storno möglich um es Plausiebel zu erklären oder sollte ich da zur Meisterschule ein bischen geschlummert haben?
    Bin da auf jeden Fall sehr offen für neue Erkenntnisse!!!

  • Zu der anderen Sache hab ich mich weiter schlau gemacht und werde Die höchste vorhandene Kundennr. aus den Attribut "kundennr" suchen und um +1 hochzählen lassen.
    Bei der Bauvorhabennummer; die eh nur Firmenintern sein soll, hab ich einfach den Zeitstempel genommen und mit dem Formatter alle Punkte etc entfernt, somit ist das immer eine eindeutige Nummer, die sich eigentlich nicht doppeln sollte. (war ein Tip von einem Lehrer für "SEMA")

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von matze511 ()

  • matze511 schrieb:

    Also ich bin der Meinung den Kunden, solange es denn nicht zu einer Rechnungslegung kam und Geld geflossen ist, kann ich unproblematisch Löschen und diese Nummer wieder verwenden. Daran sollte sich das Finanzamt keineswegs stören und auch nicht ob da Lückenschluß in den Nummern ist.
    Erst bei den Rechnungsnummern, die dann eh über die ein Rechnungsprogramm etc laufen muß ich dem Finanzamt hieb und stichfest eine fortlaufende Nummer liefern. Und da ist nur noch Storno möglich um es Plausiebel zu erklären oder sollte ich da zur Meisterschule ein bischen geschlummert haben?
    Bin da auf jeden Fall sehr offen für neue Erkenntnisse!!!
    Das ganze gilt aber auch für lieferscheine...

  • gritsch schrieb:

    matze511 schrieb:

    Also ich bin der Meinung den Kunden, solange es denn nicht zu einer Rechnungslegung kam und Geld geflossen ist, kann ich unproblematisch Löschen und diese Nummer wieder verwenden. Daran sollte sich das Finanzamt keineswegs stören und auch nicht ob da Lückenschluß in den Nummern ist.
    Erst bei den Rechnungsnummern, die dann eh über die ein Rechnungsprogramm etc laufen muß ich dem Finanzamt hieb und stichfest eine fortlaufende Nummer liefern. Und da ist nur noch Storno möglich um es Plausiebel zu erklären oder sollte ich da zur Meisterschule ein bischen geschlummert haben?
    Bin da auf jeden Fall sehr offen für neue Erkenntnisse!!!
    Das ganze gilt aber auch für lieferscheine...
    stimmt in dem Punkt hab ich dann Aussenstände, was ich erklären muß.
    Aber mir geht es hier eigentlich nur um eine Kundennr. alles andere muß ein richtiges Programm hergeben. Also nur das Angebot und Details zum Auftrag und da kann ich ja schonmal eine Kundennr. festlegen um später leichter drauf zurück zugreifen.

  • gritsch schrieb:

    matze511 schrieb:

    Bei der Bauvorhabennummer; die eh nur Firmenintern sein soll, hab ich einfach den Zeitstempel genommen und mit dem Formatter alle Punkte etc entfernt, somit ist das immer eine eindeutige Nummer, die sich eigentlich nicht doppeln sollte. (war ein Tip von einem Lehrer für "SEMA")
    Das halte ich für eine sehr schlechte Idee - aber was solls...
    Warum? Sollte ich lieber die Kundennr. nutzen mit einem Zusatz, da ja ein Kunde mehrere Aufträge haben kann?