search

minova-afis / aero.minova.rcp

Der Standard RCP Fatclient von MINOVA Abrechnung={MIN/Intern-MIN/CORE/ZPROGRAM}
Eclipse Public License 2.0
6 stars 2 forks source link

Adressen im Default-Druck an Kunden anpassen #1547

Open martins-1992 opened 6 months ago

martins-1992 commented 6 months ago

Wir müssten mal die Adressdaten für die PDF-Generierung von Reports und co. mal einheitlich gestalten.

theuerer commented 6 months ago

Bei den Rechnungen werden die Layouts kundenspezifisch programmiert. Bei der Skytanking haben wir aktuell die Adresse pro Standort hardcodiert im Rechnungsformular.

Bei Rechungs-Detaildruck ermitteln wir aktuell in der SQl-Prozedur die Adresse aus dem CompanyKey der tSite.

Die Ermittlung der Adresse erfolgte im 11-er aus der License.xbs. So wurde verhindert, dass jemand das System nutzt der der keine License.xbs hat.

janiak-minova commented 6 months ago

Im Index-Druck steht, glaube ich, immer die Minova-Adresse

Genau, siehe PrintIndexHandler. Hat soweit ich das sehe die gleiche Struktur wie auch der Detaildruck bräuchte.

Im Detail-Druck kommt es von der generierten XML. Hier bräuchten wir aber eine Konvention, damit bspw. der SQL-Code für die XML-Generierung immer aus demselben Ort sich die Adressdaten holt.

Da es um Vereinheitlichung geht und bei dem Index-Druck kein CAS-Aufruf stattfindet, würde ich es nicht im SQL-Code machen. Ich kenne mich mit den license Dateien aus System 11 nicht aus, aber deren Idee scheint mir nicht schlecht. Beim Starten der Anwendung kann das WFC die Datei genau wie die application.xbs vom CAS laden und die enthaltenen Daten sowohl im Index- als auch im Detail-Druck anwenden. Die Datei könnte auch wie die application.mdi vom CAS aus der Datenbank generiert werden. Kann keine Datei geladen werden kann wird als Fallback die Minova-Addresse verwendet.

Wie wird es für bspw. Rechnungen gemacht?

In dem einzigen Fall den ich kenne (SIS Oiltanking) wird dafür ein Birt-Report genutzt. Entsprechend sind dort die Kundendaten in der .rptdesign Datei vermerkt. In diesem Fall speichert das WFC nur die PDF ab und zeigt sie an, generiert wird die PDF vom Birt-Dienst. Beim Index- und Detaildruck generiert das WFC selbst die PDF, hat also noch Einfluss auf die Daten.

martins-1992 commented 6 months ago

Da es um Vereinheitlichung geht und bei dem Index-Druck kein CAS-Aufruf stattfindet, würde ich es nicht im SQL-Code machen.

k, dachte, dass der Detail-Druck über SQL-Code geht, wenn nicht, dann gehört es da auch nicht rein. Nur falls man immer noch einige Reports mit SQL-Code generiert, bräuchte man für diese ein Standardvorgehen.

janiak-minova commented 6 months ago

der Detail-Druck über SQL-Code geht

Sorry, ja, die "spannenden" Daten funktionieren über SQL, siehe z.B. für Invoice. Soweit ich das sehe wird aber in dem SQL Code nicht die Site ausgelesen, ich rate mal, die wurde auch in 11 von der Anwendung generiert und an den Anfang der xml Datei gepackt.

theuerer commented 6 months ago

der Detail-Druck über SQL-Code geht

Sorry, ja, die "spannenden" Daten funktionieren über SQL, siehe z.B. für Invoice. Soweit ich das sehe wird aber in dem SQL Code nicht die Site ausgelesen, ich rate mal, die wurde auch in 11 von der Anwendung generiert und an den Anfang der xml Datei gepackt.

Ja, die 11 hat die Adressdaten und Tel/Fax aus der License.xbs gezogen. Ich fände es auch gut, wenn wir diese Daten auch wieder durch die Anwendung ermitteln und zur XML hinzufügen. Woher die Daten kommen müsste noch definierert werden.

Die SQL-Prozedur habe ich jetzt als "hotfix" vor Ort angepasst bis wir hier eine Definitionmj haben.