adad95 - PraxPlan - ADTax - Forum - Ridler Datentechnik - Rezeptnummern nicht fortlaufend
adad95 - PraxPlan - ADTax - Forum - Ridler Datentechnik
adad95 - PraxPlan - ADTax - Forum - Ridler Datentechnik
Startseite | Profil | Registrieren | Neue Beiträge | Mitglieder | Suchen | FAQ
Benutzername:
Passwort:
Sprache wählen
Passwort speichern
 Alle Foren
 adad95 - Praxisverwaltung 2018
 adad95 2018 Forum - Kundenfragen - Lösungen
 Rezeptnummern nicht fortlaufend
 Neues Thema  Auf Thema antworten
 Drucken
Autor Vorheriges Thema Thema Nächstes Thema  

herrmanj

Germany
367 Beiträge

Gesendet am: - 21/08/2018 :  10:23:42  Profil ansehen  E-Mail an den Autor  Besuche herrmanj's Homepage  Antwort mit Zitat
Ich weiß nicht, ob es ein wirkliches Problem ist, aber komisch ist es schon und besser es wurde gemeldet als wenn das Problem dann akut wird. Mitunter interessiert so etwas auch die Softwareentwickler. Ich hatte jetzt schon 3x ohne Grund Sprünge um jeweils ca. 1000 Stellen in meinen Rezeptnummern in der Datenbank.



Jan H.

mechanicus

Germany
1263 Beiträge

Gesendet am: - 21/08/2018 :  11:45:35  Profil ansehen  E-Mail an den Autor  Besuche mechanicus's Homepage  Antwort mit Zitat
Sehr seltsam, zumal es nur in der 1057 (ab 05.04.2018) auftaucht.
Ich habe das bei mir mal überprüft und kann das nicht bestätigen.

Ich kann Dir nur raten, das mit dem Rezeptdatum zusammen genau zu dokumentieren und nicht zu löschen, weil ansonsten das Finanzamt bei einer Betriebsprüfung dazuschätzen wird.
Dann hättest Du Dein "wirkliches Problem".
Zum Anfang der Seite

Entwicklung

Deutschland
1705 Beiträge

Gesendet am: - 21/08/2018 :  12:10:10  Profil ansehen  Besuche Entwicklung's Homepage  Antwort mit Zitat
Die Sprünge entstehen nach dem Neustart des SQL – Servers. Das Verhalten ist bekannt und Microsoft ist der Meinung das ist so richtig. Da wir derzeit 2.147.483.648 mögliche Rezeptnummern vergeben können sehe ich die Sprünge auch entspannt.

https://social.msdn.microsoft.com/Forums/sqlserver/de-DE/ed0f5eb9-1aaf-4ece-ad86-793e9d16ef79/autoincrement-id-springt-von-1-auf-1000?forum=sqlserverexpressde

und

https://docs.microsoft.com/de-de/sql/t-sql/statements/create-table-transact-sql-identity-property?view=sql-server-2017
Siehe Aufeinanderfolgende Werte nach Serverneustart oder anderen Fehlern

Ja, es gibt auch eine SQL – Server Einstellung die das Springen der ID’s nach Neustart des Servers zukünftig verhindert. Siehe Trace Flag 272

https://docs.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-traceon-trace-flags-transact-sql?view=sql-server-2017

Zum Anfang der Seite

mechanicus

Germany
1263 Beiträge

Gesendet am: - 21/08/2018 :  13:39:01  Profil ansehen  E-Mail an den Autor  Besuche mechanicus's Homepage  Antwort mit Zitat
Zitat:
Entwicklung:    Das Verhalten ist bekannt und Microsoft ist der Meinung das ist so richtig.
Toll, mal wieder typisch für Microsoft. Die beste aller Datenbanken! Was springt denn sonst noch so im Datenbestand hin und her?
Zitat:
Entwicklung:    Da wir derzeit 2.147.483.648 mögliche Rezeptnummern vergeben können sehe ich die Sprünge auch entspannt.
Aus dem weiter oben von mir genannten Grund sehe ich das nicht so entspannt.

Bei herrmanj könnte das dann so aussehen, dass bei einem Rezeptdurchschnittswert von 100 € 3x1000x100 = 300.000 € Umsatz hinzugeschätzt würden, weil eine Löschung unterstellt wird. Das könnte natürlich mit viel Erklärungsaufwand entkräftet werden, aber wenn man an einen Prüfer kommt, der seine Statistik schönen will, ...
Zitat:
Entwicklung:    Ja, es gibt auch eine SQL – Server Einstellung die das Springen der ID’s nach Neustart des Servers zukünftig verhindert. Siehe Trace Flag 272
Das wäre eine Lösung mit Trace Flags,

aber:
Zitat:
Microsoft:    (!) Important
Trace flag behavior may not be supported in future releases of SQL Server.
Also keine Lösung!

Geändert durch - mechanicus am 21/08/2018 14:07:09
Zum Anfang der Seite

Entwicklung

Deutschland
1705 Beiträge

Gesendet am: - 21/08/2018 :  14:21:08  Profil ansehen  Besuche Entwicklung's Homepage  Antwort mit Zitat
Seit wann müssen Rezepte eindeutige Nummern haben und dürfen nicht gelöscht werden. Für die Abrechnung werden nur eindeutige Rezept- Nummern innerhalb der einen Rechnung benötigt.

Wenn wirklich die Sorge besteht, sollte man einfach die Rezeptnummern in der Rezeptliste ausblenden.

Rechnungsnummern werden anders verwaltet und können aus dem Grund Sprünge dieser Art nicht aufweisen.
Zum Anfang der Seite

4ZsumsyK8fH2

29 Beiträge

Gesendet am: - 21/08/2018 :  18:18:15  Profil ansehen  Antwort mit Zitat
Ich gebe mechanicus da völlig recht. Aus meiner Sicht ist eine fortlaufende Belegnummer, die dann plötzlich nicht mehr fortlaufend ist und größere Lücken aufweist, äußerst auffällig. Von einer Software erwartet man ja eigentlich, das alles nachvollziehbar und revisionssicher dokumentiert wird. Die nachvollziehbarkeit ist momentan aus meiner sicht so nicht ideal gegeben.
Zum Anfang der Seite

mechanicus

Germany
1263 Beiträge

Gesendet am: - 21/08/2018 :  20:44:17  Profil ansehen  E-Mail an den Autor  Besuche mechanicus's Homepage  Antwort mit Zitat
Zitat:
Entwicklung:    Wenn wirklich die Sorge besteht, sollte man einfach die Rezeptnummern in der Rezeptliste ausblenden.
Ah ja, wenn die Realität nicht passt, schließt man einfach die Augen ...

Ich bin zwar (noch) nicht betroffen, aber die Art, wie Sie die Probleme kommunizieren, ist schon bemerkenswert.

Was spricht denn dagegen, den Fehler mit wenig Aufwand abzustellen?

Eine Lösung wäre z.B., bei jeder Rezeptneuanlage abzufragen, ob der Zähler konsistent ist. Wenn nicht, wird einfach um Tausend reduziert.
Zum Anfang der Seite

Hand und Herz

150 Beiträge

Gesendet am: - 22/08/2018 :  11:26:43  Profil ansehen  E-Mail an den Autor  Antwort mit Zitat
"Das wäre eine Lösung mit Trace Flags,

aber:

Zitat:Microsoft: (!) Important
Trace flag behavior may not be supported in future releases of SQL Server.

Also keine Lösung!"

Was ist denn nun die Lösung, damit wir alle bei einer Buchführung uns auf das Programm verlassen können?
Zum Anfang der Seite

Entwicklung

Deutschland
1705 Beiträge

Gesendet am: - 22/08/2018 :  12:23:58  Profil ansehen  Besuche Entwicklung's Homepage  Antwort mit Zitat
Die Realität ist, es gibt keine Verpflichtung Rezepte zu nummerieren und die Behauptung die nicht vorgeschriebene Nummerierung müsste lückenlos aufsteigend sein, ist frei erfunden.

Um das Ganze dann noch dramatischer zu machen, kommt der böse Finanzbeamte und rechnet anhand der von fehlenden Nummern irgendwelche nicht vorhandenen Umsätze aus. Ein einfacher Betriebsprüfer des Finanzamtes hat in diesem Teil der Praxissoftware nix zu suchen und ist froh, wenn er die exportierte Buchhaltung auf seinem dienstlichen Rechner prüfen kann.

@mechanicus Nicht nur einfach behaupten Rezepte müssten lückenlos Nummeriert werden, sondern die Vorschrift benennen.


Zum eigentlichem Problem.
Bestimmte Versionen des MS – SQL Servers haben die Eigenart nach einem unerwarteten Neustart. Da springt auch nix hin und her es geht nur nach oben. Das Verhalten, sagt man, hat mit der immer wichtiger werdenden Geschwindigkeit zu tun.

Bei der Behauptung das Setzen des Trace – Flags wäre keine Lösung wurde nicht wirklich nachgelesen sondern einfach der obere allgemeine Hinweis genommen. Liest man bei dem speziellen Flag nach, so sieht man, dass beginnend mit der MS – SQL Server Version 2017 ein Ersatz, unter anderem, für dieses Flag eingebaut wurde.

Man kann also davon ausgehen, dass bei einer zukünftigen Version statt dem Flag nur noch die ‘ ALTER DATABASE SCOPED CONFIGURATION‘ funktioniert wird. Erfahrungsgemäß funktionieren beide Methoden jedoch einige Versionen parallel.

Die vorgeschlagenen programmtechnischen Lösungen funktionieren so sicher nicht. Autowert – Spalten sind immer schreibgeschützt und werden ohne Zutun bei Neuanlage des Datensatzes vom System vergeben.

@Hand und Herz. Für die Vergabe von Rechnungsnummern und Belegnummern wird nicht die hier diskutierte Funktion des MS – SQL Servers genutzt. Somit sind diese Nummern auch nicht betroffen.
Zum Anfang der Seite

mechanicus

Germany
1263 Beiträge

Gesendet am: - 22/08/2018 :  14:34:24  Profil ansehen  E-Mail an den Autor  Besuche mechanicus's Homepage  Antwort mit Zitat
Zitat:
Entwicklung    Die Realität ist, es gibt keine Verpflichtung Rezepte zu nummerieren und die Behauptung die nicht vorgeschriebene Nummerierung müsste lückenlos aufsteigend sein, ist frei erfunden.
Es bleibt doch ein Fakt, dass jedes abgerechnet Rezept als Einnahme zu buchen ist. Wenn nun anhand der Rezeptnummern in einem Zeitraum mehr Rezepte vermutet werden können, als gebucht wurden, ist das zumindest erklärungsbedürftig.
Zitat:
Entwicklung    Ein einfacher Betriebsprüfer des Finanzamtes hat in diesem Teil der Praxissoftware nix zu suchen und ist froh, wenn er die exportierte Buchhaltung auf seinem dienstlichen Rechner prüfen kann.
Völlig richtig. Nur braucht es zum Nachweis einfach nur der Rechnungen, weil auf diesen ja die Rezeptnummern vermerkt sind.
Zitat:
Entwicklung    @mechanicus Nicht nur einfach behaupten Rezepte müssten lückenlos Nummeriert werden, sondern die Vorschrift benennen.
Wo habe ich das behauptet? Ich habe nur geschrieben, dass es bei den beschriebenen Sprüngen zu Erklärungsnotwendigkeiten kommen kann, was ja wohl nicht im Ernst bestritten wird?
Zitat:
Entwicklung    Bei der Behauptung das Setzen des Trace – Flags wäre keine Lösung wurde nicht wirklich nachgelesen sondern einfach der obere allgemeine Hinweis genommen.
Das mit dem Trace Flag hatten Sie doch geschrieben:
Zitat:
    Ja, es gibt auch eine SQL – Server Einstellung (...) Siehe Trace Flag 272
Zum Anfang der Seite

Entwicklung

Deutschland
1705 Beiträge

Gesendet am: - 22/08/2018 :  15:13:28  Profil ansehen  Besuche Entwicklung's Homepage  Antwort mit Zitat
Zitat:
Es bleibt doch ein Fakt, dass jedes abgerechnet Rezept als Einnahme zu buchen ist. Wenn nun anhand der Rezeptnummern in einem Zeitraum mehr Rezepte vermutet werden können, als gebucht wurden, ist das zumindest erklärungsbedürftig.

1. Man bucht bezahlte Rechnungen und keine Rezepte.
2. Aber wohl eher vom freundlichen Finanzbeamten als vom Praxisinhaber. Die Begründung da ist eine Lücke in der Nummerierung von Rezepten wird ja wohl nicht reichen. Denn es steht nirgendwo die Nummerierung muss lückenlos aufsteigend sein


Zitat:
mechanicus Gesendet - 22/08/2018 : 14:34:24
Das mit dem Trace Flag hatten Sie doch geschrieben:


Richtig und Sie hatten dann geschrieben: Das ist keine Lösung! Diese Behauptung ist faktisch falsch.
Siehe Post vom - 21/08/2018 : 13:39:01
Zum Anfang der Seite

mechanicus

Germany
1263 Beiträge

Gesendet am: - 22/08/2018 :  15:52:34  Profil ansehen  E-Mail an den Autor  Besuche mechanicus's Homepage  Antwort mit Zitat
Zitat:
Entwicklung    
Zitat:
mechanicus    gesendet - 22/08/2018 : 14:34:24
Das mit dem Trace Flag hatten Sie doch geschrieben:

Richtig und Sie hatten dann geschrieben: Das ist keine Lösung! Diese Behauptung ist faktisch falsch.
Siehe Post vom - 21/08/2018 : 13:39:01
Mein verstorbener Vater nannte so was Wortklauberei.
Zum Anfang der Seite

Entwicklung

Deutschland
1705 Beiträge

Gesendet am: - 22/08/2018 :  16:02:26  Profil ansehen  Besuche Entwicklung's Homepage  Antwort mit Zitat
Sie sagen, das Setzen des Trace Flag ist keine Lösung.
Ich sage, diese Behauptung ist falsch, das Setzten des Trace Flags ist die Lösung wenn man denn den SQL Server veranlassen will die Nummern (ID's) ohne Lücken zu vergeben.
Wo ist da die Wortklauberei
Zum Anfang der Seite

mechanicus

Germany
1263 Beiträge

Gesendet am: - 22/08/2018 :  16:50:29  Profil ansehen  E-Mail an den Autor  Besuche mechanicus's Homepage  Antwort mit Zitat
Das versteht doch nun hier wirklich keiner mehr.

Warum beheben Sie den Fehler nicht einfach mit Ihrem Trace Flag statt hier zu argumentieren, der Fehler wäre kein Fehler und wenn, dann nicht so schlimm.

Zum Anfang der Seite

herrmanj

Germany
367 Beiträge

Gesendet am: - 24/08/2018 :  12:03:13  Profil ansehen  E-Mail an den Autor  Besuche herrmanj's Homepage  Antwort mit Zitat
Zitat:
Ersterfassung durch Entwicklung

Ja, es gibt auch eine SQL – Server Einstellung die das Springen der ID’s nach Neustart des Servers zukünftig verhindert. Siehe Trace Flag 272

https://docs.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-traceon-trace-flags-transact-sql?view=sql-server-2017




Hier noch mal der Link für Forenmitglieder die des angelsächsischen nicht so mächtig sind

https://docs.microsoft.com/de-de/sql/t-sql/database-console-commands/dbcc-traceon-trace-flags-transact-sql?view=sql-server-2017
Zum Anfang der Seite

herrmanj

Germany
367 Beiträge

Gesendet am: - 24/08/2018 :  12:15:38  Profil ansehen  E-Mail an den Autor  Besuche herrmanj's Homepage  Antwort mit Zitat
Ich habe mich mal in den Stoff etwas reingelesen und denke die Lösung mit den Trace Flags wird dem normalen Anwender (so wie ich) etwas zu kompliziert sein.

Es ist ja gut zu wissen, dass es eine Lösung gibt, aber wenn ich sie nicht anwenden kann, ist es in dem Sinne für den Nutzer eben doch irgendwie keine Lösung.

Ich sehe 3 Möglichkeiten wie es weiter gehen könnte:

1. Es bleibt alle wie es ist.
2. RD findet eine Lösung auf der adad95-Seite.
3. RD schreibt eine Hantierungsanweisung, was genau bei der SQL-DB mit "trace flag 272" zu machen ist.

Ich würde mich über 2. freuen und wäre über 3. nicht böse.
Zum Anfang der Seite
  Vorheriges Thema Thema Nächstes Thema  
 Neues Thema  Auf Thema antworten
 Drucken
Springe zu:
adad95 - PraxPlan - ADTax - Forum - Ridler Datentechnik © Ridler Datentechnik Zum Anfang der Seite
 Image Forums 2001 Powered By: Snitz Forums 2000 Version 3.4.06