adad95 - PraxPlan - ADTax - Forum - Ridler Datentechnik
adad95 - PraxPlan - ADTax - Forum - Ridler Datentechnik
adad95 - PraxPlan - ADTax - Forum - Ridler Datentechnik
Startseite | Profil | Registrieren | Neue Beiträge | Mitglieder | Suchen | FAQ
 Alle Foren
 adad95 - Praxisverwaltung
 adad95 Forum - Kundenfragen - Lösungen
 Rezeptnummern nicht fortlaufend

Hinweis: Sie müssen sich registrieren, um eine Antwort zu erstellen.
Um sich zu registrieren, klicken Sie hier. Die Registrierung ist KOSTENLOS!

Auflösung:
Benutzername:
Passwort:
Funktion:
Format: FettKursivUnterstreichenDurchstreichen Links ausrichtenZentrierenRechts ausrichten Horizontale Line Hyperlink einfügenE-Mail einfügenBild einfügen Code einfügenZitat einfügenListe einfügen YouTube Video einfügen
   
Nachricht:

* HTML ist AUS
* Forum Code ist EIN
Smilies
Lächeln [:)] Lachen [:D] Cool [8D] Erröten [:I]
Lechzen [:P] Teufelchen [}:)] Zwinkern [;)] Clown [:o)]
Verletzt [B)] Volltreffer [8] Stirnrunzeln [:(] Schüchtern [8)]
Bestürzt [:0] Verärgert [:(!] Niedergeschlagen [xx(] Schläfrig [|)]
Küsse [:X] Zustimmung [^] Missbilligung [V] Frage [?]

 
   

T H E M A      Ü B E R S I C H T
herrmanj Gesendet - 21/08/2018 : 10:23:42
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.
14     L E T Z T E      A N T W O R T E N    (Die neueste zuerst)
herrmanj Gesendet - 24/08/2018 : 12:15:38
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.
herrmanj Gesendet - 24/08/2018 : 12:03:13
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
mechanicus Gesendet - 22/08/2018 : 16:50:29
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.

Entwicklung Gesendet - 22/08/2018 : 16:02:26
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
mechanicus Gesendet - 22/08/2018 : 15:52:34
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.
Entwicklung Gesendet - 22/08/2018 : 15:13:28
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
mechanicus Gesendet - 22/08/2018 : 14:34:24
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
Entwicklung Gesendet - 22/08/2018 : 12:23:58
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.
Hand und Herz Gesendet - 22/08/2018 : 11:26:43
"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?
mechanicus Gesendet - 21/08/2018 : 20:44:17
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.
Entwicklung Gesendet - 21/08/2018 : 14:21:08
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.
mechanicus Gesendet - 21/08/2018 : 13:39:01
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!
Entwicklung Gesendet - 21/08/2018 : 12:10:10
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

mechanicus Gesendet - 21/08/2018 : 11:45:35
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".

adad95 - PraxPlan - ADTax - Forum - Ridler Datentechnik © Ridler Datentechnik Zum Anfang der Seite
 Image Forums 2001 Powered By: Snitz Forums 2000 Version 3.4.06