Speichern Belege Fehler (Belegtyp)

[Bisut]

Wir haben einen Kunden von 8.0 auf 9.0 auf einem Windows Terminal Server umgestellt. Nach der Umstellug kommt "sporadisch" (manchmal öffters am Tag, manchmal zwei Tage lang nichts) der Fehler beim Speichern von Belegen. Siehe bitte Anlage.
Fehler: Keine Eingabe im Pflichtfeld: Belegtyp

Aber es ist völlig egal, welcher Vorgang bearbeitet wird. Ob nun im Einkauf oder Verkauf; und völlig unabhängig vom User. Auch egal, ob neuer Beleg oder bestehender Beleg. Nach Aussage der Mitarbeiter passiert es auch, wenn ein Beleg längere Zeit offen bliebt und dann weiter gearbeitet wird.

Ich habe die Vermtung im Applikation Server. Aber nur so vom Gefühl. Jemand ähnliches Problem schon gehabt oder könnte sich vorstellen, woran es liegen kann?

Die Datenbank war schon bei der Prüfung bei uns, an der Datenbank liegt es selber nicht.

 

[Manuel Goldschmidt]

mal ne Frage am Rande... wie schafft man es einen Beleg "anzulegen/editieren" ohne das eine Vorauswahl oder der letzte Belegtyp automatisch gefüllt wird...??? Und wohin verweist dann tatsächlich die Fehlermeldung?

 

[Hardy Buchholz]

Ja, den Fehler kennen wir. Tritt relativ zuverlässig auf, wenn man per RDP an einer VM arbeitet und die Verbindung unterbricht. Nach Neuaufbau der Verbindung hat man dann diesen Fehler. Ärgerlich, wenn man schon viele Positionen erfasst hat, ohne zu speichern.
Man kann sich behelfen, indem man eine neue Position einfügt und speichert, dann "fängt" sich die Belegerfassung wieder und alles ist OK.
Tritt bei uns aber in der 8.1.. auf.

 

[Bisut]

@Manuel Goldschmidt = Gar nicht, das ist ja nicht der Fehler, das die Sage "keinen Belegtyp" hat, der ist natürlich da.

@Hardy Buchholz = Guter Ansatz, aber wo ist die dauerhafte Lösung? (Also was tenisches und Lösung ist auserhalb der Sage zu suchen?)

 

[m.becker]

Eine wirkliche Lösung habe ich auch noch nicht gefunden, aber man kann als Workaround einfach die Belegart wieder auswählen und dann auch sofort wieder speichern.

 

[Bisut]

Das mit dem Workaround "Belegart wieder auszuwählen und dann zu speichern" - funktioniert hier bei dem Kunden leider nicht. Das haben wir schon probiert. Fehler bleibt dann auch bestehen, wenn man das macht.

Die User haben zur Zeit die Zwischenlösung, immer wieder auf Speichern zu klicken und nicht viele Positionen auf einmal zu ändern bzw. neu einzutragen. Wir werden als erstes nächste Woche, die Sage komplett neu aufsetzen um hier auch Fehlerquellen zu vermeiden.

 

[Jan Lehmann]

Hallo,
könnten Sie diesen Sachverhalt an Sage melden. Ich habe es bereits gemeldet. Bei Sage ist dazu nichts bekannt, aber wenn es mehrer melden wird es wahrscheinlich priorisiert.

 

[Bisut]

@Jan Lehmann = haben wir bereits, aber da kam leider nicht viel bei raus.

Sage ist dieses als Fehler nicht bekannt. Und Nachstellen können wir dieses halt auch nicht.

Wir haben heute Nachmittag beim Kunden einen Einsatz. Hier wird alles neu gemacht, wir wollen Fehlerquellen ausschließen.

Das war auch erstmal der Ansatz der Sage Supporter. Eigentlich hatten die uns nur geschrieben:

"Fehler nicht bekannt, lässt sich das nachstellen?" oder "ist der Fehler auch im Demo Mandanten vorhanden?".

Also wirklich keine ansprechende Lösung!

Aber anscheindend sind wir ja mit dem Probelm nicht allein. Vielen Dank noch an das Forum.

Der EDV Betreuer hat uns hier versichert, das die Einwahl " RDP an einer VM" nicht das Problem sein kann!

Da diese Verbindung schon seit bestehen der Sage so ist. Bis Version 8.0 (allerdings mit alter Oberfläche) gab es ja keine Probleme. Erst mit 9.0 und der neuen Oberfläche.

Der Kunde möchte auf gar keinen Fall wieder auf die alter Oberfläche zurück, weil das Ziel von Sage ja die neue Oberfläche ist und einige Bereich in der Sage sowieso automaitsch neue Oberfläche sind.

Wollen heute mal sehen, was der ganze Aufwand bringt. Zumindest für den Kunden alles kostenlos, weil er sonst den Einatz der Sage für die Zukunft in Frage stellt.

 

[tfluegel]

Hallo zusammen,

ich habe gerade in unseren Systemen nach dem Thema gesucht und es auch gefunden. Wir hatten leider nur Client-seitige Log-Dateien bekommen, in denen keine Auffälligkeiten vorhanden waren. Die Kollegen hatten das Ticket daher geschlossen. Wenn hier ein Problem vorhanden ist, wird dies aber Server-seitig liegen, wie @Bisut ja schon ganz am Anfang vermutet hat. Wenn das also reproduzierbar ist, dann bitte nochmals an den Sage System-Support wenden und die kompletten Logs (Client und Server) sowie alle Infos dazu einreichen. Dann sehen wir uns das noch einmal an.

Viele Grüße
Thomas Flügel
Sage GmbH

 

[Jan Lehmann]

Hallo Herr Flügel,

ich konnte es in dem DemoDB nachstellen(wie Herr Buchholz) geschrieben hat und habe das TraceLog zum Ticket hochgeladen.

 

[Bisut]

Wir haben folgendes gemacht, seit dem trat der Fehler nicht wieder auf:

SAGE Basis Server (Windows 2019 Server / 12 GB Virtualisiert); neuer bestellt. Lieferung Anfang April

SQL Express, DB Kunde gesichert, DB Global gesichert in beiden die LogFiles verkleinert (SQL Standard bestellt)

Änderungssetup der Sage100 / 9.0 mit LiveUpdate Neuprüfung

SQL Express Eigenschaften Arbeitsspeicher von Dynamisch auf mindestens 8 GB geändert und SQL Dienst neu gestartet

Datenbank Aktualisiert und Datenbank Reorganisation durchgeführt

Applikation Server, Standard Einstellung der Asynchrone Isolationsprozesse (5/1/5) auf (5/3/15) geändert und Dienste neu gestartet; Wert kann ja jederzeit auf Standard wieder zurück gebracht werden.

OL Admin, Kundenfeedback auf Nein gestellt, Sage100 Prozesse (2ter Haken) raus genommen; auf Terminal Server soll dieser eh nichts bringen.

Kontrolle der Ports (5493/5494) sind dort richtig, und sind in der Firewall auch richtig gesetzt

Terminal Server 2012 / 28 GB (Virtualisiert); auch hier wird Anfang April ein neuer kommen.

Änderungssetup der Sage100 / 9.0 im Modus „Install“ für WTS; Client Ausführungen

LiveUpdate ausgeführt.

Kontrolle über Wartungsclient Sage = alles OK.

Kundenfeedback: seit einer Woche kam der Fehler nicht mehr!

 

[cmayer]

Wir kennen dieses Problem in der Sage 100 9.0.1.2 auch.

Ebenfalls im Zusammenhang mit RDP-Sitzung / TerminalServer - wenn diese länger inaktiv war.
Ich hatte ebenfalls die Einstellungen des Sage Application-Servers in Verdacht... ... und hier auch schon etwas geschraubt.

Allerdings hatten wir das schon immer eher selten - und tatsächlich lässt sich der Beleg in der Regel "retten" mit "Zeile einfügen" - oder auch "neu nummerieren".

Ich werde weiter beobachten... und gegebenenfalls berichten

 

[Bisut]

Die Maßnahmen haben leider nicht lange gehalten
Kunde bekommt wieder vermehrt die gleichen Fehler! Nach dem der Kunde nun Hardwarewechsel vornimmt (Ende März), werden wir das Problem leider weiter verfolgen müssen. Der Terminal Server wird zur Zeit jeden zweiten Tag neu gestartet, aber das allein bringt wohl nichts. Alles ziemlich ärgerlich. Wir werden nach Serverwechsel dann an Sage erneut ein Ticket aufmachen. Sehr schade, ich dachte es wäre alles gut.

 

[alois_m87]

hallo zusammen, hat hier jemand eine lösung zu dem problem schon gefunden ?

wir haben auch so ein problem, können uns derzeit nur mit datenbank aktualisieren im administrator behelfen.

 

[Bisut]

@alois_m87
Eine Löung haben wir so hin bekommen, das kann bei Ihnen allerdings anders sein.

Die Datenbank des Kunden wird nun regelmässig über den SQL Wartungsplan mit "den Indiezes" (Index neu erstllen, Index neu organisieren) erstellt. Das war vorher nie der Fall. Der Index war bei unserem Fall hier nie vorher richtig erstellt worden. Das lag daran, das Kunde vorher immer nur den SQL Express im Einsatz hatte und wir grundsätzlich nur über den Standard SQL Wartungspläne erstellen und nicht über Skripte, wie andere Business Partner.

Zum weiteren gab es hier auch ein Serverwechsel (neues Betriebssystem Windows Server 2019) und zusätzlich auch ein Upgrade auf die 9.0 Version. Nach dem ersten Mal des Neuaufbaus des Index war hier die Fehlermeldung deutlich zurück gegangen. Und nach dem Serverwechsel dann nochmals. Ob das nun mit dem Serverwechsel oder mit der Version 9.0 zusammehnängt können wir so nicht mehr bestätigen. Zumindest hat unser Endkunde seit dem nicht wieder diesen Fehler bekommen.

 

[tfluegel]

Wir haben gerade in diesem Bereich endlich einen Fehler gefunden. Er soll voraussichtlich nächste Woche mit Version 9.0.2.3 gefixt werden.

Viele Grüße
Thomas Flügel
Sage GmbH

 

[Bisut]

@tfluegel = Danke! Gute Nachrichten. Obwohl es bei unseren Kunden nicht wieder aufgetreten ist, werde ich das Update natürlich einspielen lassen.