Übersetzung von Benutzerfeldern

[s.rast]

Guten Tag zusammen,

ist es eigentlich möglich, Benutzerfelder bei fremdsprachigen Belegen übersetzen zu lassen? Bisher bin ich davon ausgegangen, dass bei Belegdruck "alle" Felder für die Übersetzung abgefragt werden, die an den Report übergeben werden.

Konkret habe ich Benutzerfelder am Artikelstamm, die ja automatisch an die Belegposition übernommen werden (sofern entspr. Felder vorhanden sind.) Einige Daten dieser Benutzerfelder sind Texte die auf Deutsch vorliegen. Bei einem Fremdsprachigen Beleg wäre es enorm hilfreich, wenn diese Felder auch durch den Übersetzungs-Assistenten ( Wörterbuch ) abgefragt würden.

Bisher dachte ich, das geht im Standard, habe mich hier vermtl. aber geirrt.

Hat hier jemand eine Idee, wie ich das realisieren könnte?

Update 1: Ich nutze die neue Reporting Engine

 

[tbarthel]

Wir haben das mal sehr aufwendig im Belegdruck gelöst. Die Office Line und die Sage100 sind nun mal keine Übersetzungsprogramme, sondern auslesbare Felder werden durch die gespeicherte Übersetzung im Wörterbuch ersetzt. Dabei können die Textfelder übersetzt werden, aber nicht deren Inhalt. Genau das passiert dann eben auch bei benutzerdefinierten Feldern.
Hoffentlich habe ich mich verständlich ausgedrückt

 

[s.rast]

Guten Morgen und vielen Dank für das Feedback
Ich denke, ich werde hier einfach für meine Zweitsprache ein weiteres Userfield anlegen und im Belegdruck je nach Sprache das eine oder andere Feld aktivieren.

Herzlichen Dank nochmal

 

[Steffen Heil]

Hallo,
eines vorweg: ich arbeite kaum noch im Belegdruck der OL / S100, daher alles ohne Gewähr. Aber ich habe sowohl mit dem Access-Print als auch dem Stimulsoft-Reporting (AppDesigner) einige größere Projekte umgesetzt.

In mehreren Projekten auf Basis des Access-Prints hatten wir ähnliche Anforderungen und diese damit gelöst, die Werte aus dem Benutzerdefinierten Feld per Code auf Label-Feldern zu platzieren. Somit wurde der Text, obwohl dynamisch aus der DB geladen, zur Übersetzung vorgeschlagen. Eventuell könnten Sie prüfen, ob dieser Ansatz auch mit dem neuen Reporting funktioniert. Zwei (oder noch mehr) Felder der Übersetzung wegen zu führen kann je nach Verwendung einen ziemlichen Rattenschwanz mit sich ziehen.

Hintergrund:
Im "klassischen" Belegdruck per Access wird zwischen Bezeichnungsfeldern (Labels) und Textfeldern unterschieden. Die Bezeichnungsfelder enthalten statische Werte, z.B. die Spaltenüberschriften, die Textfelder hingegen die Inhalte aus der Belegerfassung. Beispiel: "Bearbeiter: Lieschen Müller" -> "Bearbeiter" steht in Label, "Lieschen Müller" in Textfeld.
Beim Druck für fremdsprachige Kunden werden nur Labels zur Übersetzung angeboten, was auch Sinn ergibt: die Inhalte der Textfelder sollen entweder gar nicht übersetzt werden (Frau Müller heißt auch in Englisch so) oder wurden bereits bei Belegerstellung übersetzt erfasst (Beispiel: englischsprachige Artikeltexte).
Dieses Schema zieht sich auch durch das neue Reporting. Hier existieren zwar keine verschiedenen Feldtypen "Label" und "Text", aber es wird unterschieden, ob einem Textfeld ein statischer Wert hinterlegt ist oder nicht.

 

[s.rast]

Hi Steffen und danke für deinen Lösungsansatz! Ich werde mir das jetzt einmal ansehen.
Du hast völlig recht, bei mehr als einem Feld wird über kurz oder Lang ein großes Durcheinander entstehen.
Auch z.B. beim Infodruck wäre dein Ansatz besser, weil der Sprachcode ja nicht im Standard in die tKHKPrint* Tabellen übertragen wird.

Weißt du noch, wo im Stimulsoft die Unterscheidung zwischen Statischem und dynamischen Text gemacht wird? Die Bezeichnungen lbl und txt wurden ja übernommen. Dankeschön!

Update 1 :
Ich habe ein Textfeld im Report erstellt. Die Übersetzung wird auch direkt vor dem Druck abgefragt. Soweit okay. Dann habe ich in Stimulsoft den Wert des Labels durch den Wert des Datenfeldes durch Code in dtbVKSubPositionArtikel ersetzt.
(lblGefahrtext.TextValue = dtsVKSubPositionArtikel.tKHKPrintPositionArtikelVK_USER_UNVersandDE)

Die Ersetzung funktioniert, aber eine Übersetzung wird nicht abgefragt.
Ergo: Ich denke im Code des Report ist es zu spät. Vermutlich werden die Labels vor dem Rendern des Reports durch Sage abgefragt. Hier komm ich vermtl. ohne eine .Net Anpassung nicht weiter, oder?

 

[AdminTR]

Falls es nicht allzu viele verschiedene 'TextValues' gibt, kannst du es mal so versuchen: Im AppDesigner kann der Feldinhalt an Bedingungen geknüpft werden. Bei z.B. Feldinhalt ist 'Brot' und Sprache ist englisch, dann wird der Ausdruck 'Bread' zugewiesen. Für weitere Feldinhalte können die UND-Bedingungen mit ODER verschachtelt werden.

Ich benutze das für besondere benutzerdefinierte Felder in den Zahlungsbedingungen.

 

[diakh]

Über die DCM "PrintVKPrepareBelegPositionCollection" könntest Du die Collection der Positionen, die beim Druck von Verkaufsbelegen für den Aufbau der temporären Drucktabellen verwendet wird, per Code anpassen und somit z.B. auch die Inhalte der benutzerdefinierten Felder über das Wörterbuch übersetzen lassen.
Im Kontext bekommst Du u.a. das Belegobjekt und die Collection der Positionen übergeben. Über das Belegobjekt kannst Du die Sprache abfragen und dann beim Druck eines fremdsprachigen Belegs die Collection der Positionen durchlaufen und beim Positionstyp "Artikel" die benutzerdefinierten Felder übersetzen:
positionen.set_UserProperty("USER_XYZ", mandant.TranslationService.GetTranslation(beleg.Sprache, positionen.get_UserProperty("USER_XYZ").ToString(), true));