Verständnisfrage Technische Datenblätter

Hallo Gemeinde,

meine Geschäftsleitung ist mit der Bitte an mich herangetreten um auszuloten, in wie weit man technische Datenblätter aus NAV erzeugen lassen kann und die Informationen im System evtl. auch für Etiketten nutzen kann.

Meine Vorstellung geht dahin, das ich Textbausteine erstelle und mir einen Report erstelle, wo ich die Textbausteine ausgeben lasse. Da es aber auch Sprachen betrifft, die Dynamics nich anzeigen kann (PL,CZ,RU) habe ich hier kleine Bedenken.

Gibt es noch einen eleganteren Weg? Wie mach ihr das im allgemeinen.

Mit technischen Datenblätter meine ich Whitepaper zu unseren Produkten.

Hallo Gemeinde,

meine Geschäftsleitung ist mit der Bitte an mich herangetreten um auszuloten, in wie weit man technische Datenblätter aus NAV erzeugen lassen kann und die Informationen im System evtl. auch für Etiketten nutzen kann.

Meine Vorstellung geht dahin, das ich Textbausteine erstelle und mir einen Report erstelle, wo ich die Textbausteine ausgeben lasse. Da es aber auch Sprachen betrifft, die Dynamics nich anzeigen kann (PL,CZ,RU) habe ich hier kleine Bedenken.

Gibt es noch einen eleganteren Weg? Wie mach ihr das im allgemeinen.

Mit technischen Datenblätter meine ich Whitepaper zu unseren Produkten.

Woher kommt deine Überzeugung dass NAV das nicht anzeigen kann?
Es gibt NAV auch für Rußland, Polen und Tschechien in einer übersetzten Version.

Es hängt einfach von den Captions ab, die du hinterlegst und ob deine Lizenz das erlaubt mehrere Sprachlayer zu benützen (soviel ich weiss).

Und das Stichwort "technische Datenblätter" klingt für mich nach angehängten Dokumente in PDF oder CAD Format. Das ist das Klammersymbol oben Mitte (bei NAV 2009 CC).

Mein MSP meinte damals zu mir, dass Russische Zeichen nicht angezeigt werden können. Das sehe ich auch, wenn ich bei uns im GSM Modul bin, dass RS Sätze in PL, CZ, RU nur mit einem Stern angezeigt werden.

Zum Thema technische Datenblätter: Meine Geschäftsleitung bildet sich ein, dass man technische Dokumente, welche man vereinheitlicht darstellen kann in einem Report erzeugen kann. Dazu sollen auch Artikelmerkmale und eben Textbausteine genutzt werden.

Nun meine Frage, kann man das so machen, oder gibt es elegantere Wege? Derzeit sind alle technische Dokumente in Word erfasst.

Meine Geschäftsleitung bildet sich ein, dass man technische Dokumente, welche man vereinheitlicht darstellen kann in einem Report erzeugen kann. Dazu sollen auch Artikelmerkmale und eben Textbausteine genutzt werden.

Das kommt auf den Umfang eurer technischen Datenblätter an. Geht es nur um ein Blatt, wo ein paar technische Daten drauf stehen, kann man das sicherlich mit einem Report und bei Artikeln hinterlegten Merkmalen (Kein NAV Standard) lösen. Geht es aber um Sicherheitsdatenblätter mit komplizierteren Texten, die Merkmale im Text enthalten oder aufwändigere Formatierungen enthalten sollen, sehe ich das auch eher in einem angehängten Word/PDF- Dokument.

Gruß, Fiddi

Wir machen hier solche einseitigen Datenblätter mit den Artikeldaten, ggf. mit den Textbausteinen. Über deren Schönheit kann man allerdings streiten

Mein MSP meinte damals zu mir, dass Russische Zeichen nicht angezeigt werden können. Das sehe ich auch, wenn ich bei uns im GSM Modul bin, dass RS Sätze in PL, CZ, RU nur mit einem Stern angezeigt werden.

Wurden die Daten irgendwie importiert?
Welcher Felder sind betroffen? Description- und Code- oder nur Code-Felder?

1. Es gibt doch NAV-Lösung speziell für den CAD-Bereich, bspw. Cosmoconsult bietet da was an.
2. Warum wollt ihr die Datenblätter in NAV erstellen lassen? Ändern sich denn eure Artikel bzw. deren Datenblätter so häufig, daß man da eine Integration bräuchte? Nach meinem Verständnis sollte doch ein Datenblatt zu einem Artikel recht statisch sein. Damit würde es sich eher anbieten, diese Dokumente einmalig extern (Word, PDF, etc.) zu erstellen und dann geschickt einen Prozeßablauf zu organisieren, bei dem die jeweiligen Datenblätter möglichst einfach an den benötigten Stellen hinzugenommen werden. Evtl. kann man hier auch etwas automatisieren, müßte man sich mal im Detail ansehen.

Nach meinem Verständnis sollte doch ein Datenblatt zu einem Artikel recht statisch sein

Wenn du das aber für alle "Zylinderschraube mit Innensechskant" in allen Durchmessern und Längen haben möchtest, produzierst du eine ganze Menge Dateien, die sich nicht wirklich unterscheiden. Und auch diese Dateien wollen erst einmal erstellt werden.

Wie schon gesagt, es kommt immer auf den Zweck an

Gruß,Fiddi

Solche Datenblätter werden in der Regel schon beim Entwurf des Artikels erstellt. Wenn der Artikel in NAV geführt und benutzt wird, sollten diese Dokumente also schon lange vorhanden sein. Wie gesagt, es liegt dann an der Organisation diese Dokumente und bei entsprechender Masse an Dokumenten auch das richtige Dokument dem jeweiligen Vorgang in NAV zuzuordnen. Das kann man organisatorisch hinbekommen oder auch in irgendeiner Weise (teil-)automatisiert, kommt aber auf die konkrete Situation in dem Unternehmen an, wie man es machen kann und was sich da lohnt.

Wir haben das mit den Texten bei uns in einer extra Tabelle "DataStore" gelöst:

Code:

myDatastore.SETRANGE(TableNo,NoOfTable);
myDatastore.SETRANGE("No.", ItemNo);
myDatastore.SETRANGE(Type, StoreType);
myDatastore.SETRANGE("Language Code", LanguageCode);

als PK, sowie ein Blob-Spalte für die Daten.

Im Storetype speichern wir eine Textbegriff (z. B. "FULLDESCRIPTION"). Das ist damit beliebig erweiterbar und kann praktisch für jede Tabelle (Item, Customer, Manufacturer,Productgroup, ...) benutzt werden.

In die Forms haben wir das über einen Button ("OpenEditor") und eine Subform mit Filter auf Tabelle, No, Storetype des aktuellen Artikels angelegt. In der Subform steht dann in einer Tabelle Language und * für vorhandenes Blob.

Was man nun in das Blobfeld speichert (HTML, RTF, Word-Doc,...) kann man durch Auswahl eines passenden Editors oder durch füllen der Felder per Webservice ja frei entscheiden.

Volker

Mein MSP meinte damals zu mir, dass Russische Zeichen nicht angezeigt werden können. Das sehe ich auch, wenn ich bei uns im GSM Modul bin, dass RS Sätze in PL, CZ, RU nur mit einem Stern angezeigt werden.

Wurden die Daten irgendwie importiert?
Welcher Felder sind betroffen? Description- und Code- oder nur Code-Felder?

Die Daten kommen aus unserem Gefahrstoffprogramm. Dort gibt es auch die Möglichkeit TM's zu erstellen, leider kostet diese Möglichkeit aber einige Taler.

@HattrickHorst: Wir sind aber leider bei einem anderen ERP Anbieter.

Es ist richtig, dass die TM's alle schon existieren. Unsere GF möchte diese aber nun in das ERP integrieren, sodass Datenpflege nur an einem Punkt angewandt werden muss.

@HattrickHorst: Wir sind aber leider bei einem anderen ERP Anbieter.

Es ist richtig, dass die TM's alle schon existieren. Unsere GF möchte diese aber nun in das ERP integrieren, sodass Datenpflege nur an einem Punkt angewandt werden muss.

Hmm, was spricht dagegen, dass dich die Geschäftsführung deiner Firma zu intensiven Schulungen bei eurem ERP-Anbieter schickt?

Ich frage mich, ob du das Produktionsmodul in Standard-NAV bzw. die Branchenlösung eueres NAV-Partners gut kennst?

Wir sind aber leider bei einem anderen ERP Anbieter.

Das war ja nur ein Beispiel. Es gibt da sicherlich auch noch andere Lösungen. Außerdem kann man in der Regel auch Module von anderen Anbietern hinzukaufen. Aber das kann man alles am besten mit eurem aktuellen Partner besprechen.

Allerdings kommen mir da ganz andere Bedenken...

Es ist richtig, dass die TM's alle schon existieren. Unsere GF möchte diese aber nun in das ERP integrieren, sodass Datenpflege nur an einem Punkt angewandt werden muss.

Wenn ich das so höre, dann habe ich das Gefühl, daß hier mit Kanonen auf Spatzen geschossen wird. Sich ein ganzes Modul zur Erstellung, Bearbeitung, Verwaltung und (automatischen) Integration von technischen Datenblättern entwickeln zu lassen bzw. eine komplette Branchenlösung zu kaufen und zu integrieren, nur damit man seine Dokumente zentral verwalten kann, wird aus meiner Sicht deutlich zu hohe Kosten verursachen.

Wo steckt hier eigentlich das Problem? Warum möchte die GF das auf einmal? Werden zu oft die falschen oder keine Datenblätter angehangen? Wie oft ändern sich denn diese Dokumente?

Aus meiner Sicht reicht es meistens aus, seinen Fileserver (oder falls vorhanden DMS) aufzuräumen und ordentlich zu strukturieren und den Rest organisatorisch abzufangen. Mit relativ wenig Aufwand lassen sich dann die Datenblätter mit dem jeweiligen Artikel in NAV verbinden, so daß jeder schnell zu den entsprechenden Dokumenten findet.

Hallo Hattrick,

unsere TMs ändern sich relativ selten. Ich finde das auch unsinnig, das in einem ERP zu machen, aber wenn es der Chef möchte.

Alle Chefs reagieren aber auch auf Kosten! Ich frage mal etwas ketzerisch, inwieweit verstehen denn Chefs, was wirkliche Integration bedeutet? Ich würde mir mal ein paar Angebote für eine "echte" Integration einholen und die dann der o.g. organisatorischen Lösung (auch kostentechnisch) gegenüberstellen. Ich meine, wenn man den Artikeln jeweils alle benötigten Datenblätter als Link hinterlegt und die User diese dann direkt aus NAV aufrufen und bearbeiten können, dann ist das ja auch eine gewisse Art der Integration. Muß man nur geschickt zu verkaufen wissen.

Alle Chefs reagieren aber auch auf Kosten! Ich frage mal etwas ketzerisch, inwieweit verstehen denn Chefs, was wirkliche Integration bedeutet? Ich würde mir mal ein paar Angebote für eine "echte" Integration einholen und die dann der o.g. organisatorischen Lösung (auch kostentechnisch) gegenüberstellen. Ich meine, wenn man den Artikeln jeweils alle benötigten Datenblätter als Link hinterlegt und die User diese dann direkt aus NAV aufrufen und bearbeiten können, dann ist das ja auch eine gewisse Art der Integration. Muß man nur geschickt zu verkaufen wissen.

Ich glaube meinem Chef geht es eher darum, dass die Rohdaten in NAV vorliegen und dort nur bearbeitet werden, damit diese in entfernter Zukunft auch auf Etiketten genutzt werden können. Dort weiß ich auch nicht, wie ich das umsetzen soll.

...damit diese in entfernter Zukunft auch auf Etiketten genutzt werden können. Dort weiß ich auch nicht, wie ich das umsetzen soll.

Dann bist Du doch wieder bei einer Lösung, die in etwa so aussieht wie ich oben schon beschrieben habe (Texte in Blobfeld).

Zusätzlich würde ich bei den Artikeln ein bool-Feld (TM notwendig) anelgen. Auf dieses Feld prüfst Du bei Lieferschein und Rechnung:

Fall TM werden in NAV gespeichert und bearbeitet: Falls für den Artikel in der richtigen Sprache keine TM in NAV vorhanden erfolgt Fehlermeldung und kein Druck des Belegs. Erst wenn TM erstellt und in NAV vorhanden erfolgt der Druck inkl. Druck der TM.

Fall TM liegt außerhalb NA(aktuell): Nachfrage, ob TM bereits separat ausgedruckt wurde. Diese Aussage wird irgendwo geloggt (in NAV im Lieferschein, Username, Uhrzeit).

Volker