Heart-Profit ERP

Als ik de tekst in een MSDS wil aanpassen (in o.a. rubriek 9) dan kan ik via 1-1-7-5-3 een item selecteren (bijvoorbeeld VOS) en dan bekijken via F5 -F5. echter als ik dan afsluit met esc (dus geen wijziging wil toepassen) en ik maak van een artikel een MSDS dan verschijnt het item (in dit geval VOS) met een aantal regels erboven, eronder en totaal anders uitgelijnd dan de rest van het document.
Hoe is dit te corrigeren?
 :scratching:

Betreft het een MSDS die in HTML is opgebouwd?

ik denk van wel.

Als je een MSDS opbouwt, worden teksten (die je met de oude editor geregistreerd hebt) onder een bepaalde style class opgenomen (bijv. div class = msds_tdsr_text).

Als je TD teksten met de DHTML editor registreert, bepaal je zélf volgens welke style class je dit doet; immers, je maakt een HTML tekst die 'gepaste' wordt in je MSDS. Grote kans dus dat je die tekst niet zelf hebt voorzien van een style tag, en dat "standaard" er niet ingesprongen wordt.

Anders geformuleerd: om je MSDS er mooi in HTML uit te krijgen, moet je wel eerst een paar zaken goed ingericht hebben. Het is niet een kwestie van "zet de parameter om en alles ziet er gelikt uit".

Zie ook http://ha1.heartprofit.nl/profit/index.php?topic=19601.0

Volgens het voorbeeld van BKienhuis zijn jullie dus wel degelijk met het HTML bezig.
Nieuw is dus misschien je TD teksten in de DHTML editor, waarmee je (als je dat zelf niet regelt) je nu geen style class aanstuurt.

Aanvullend:
Als je teksten met de DHTML editor registreert, worden de oude dos-tekst naar DHTML vertaald zodra je de tekst wijzigt.
Na F5 ziet het er dus vanzelf al anders uit...

Merk ook op dat jullie deze (http://ha1.heartprofit.nl/profit/index.php?topic=20832.0) aanpassing nog niet hebben.

Ik ben inmiddels bezig geweest met toevoegen van style tags en qua layout klopt het nu wel weer. Alleen krijg ik de getallen bij vlampunt, dichtheid, soortelijke massa e.d. nog niet in het document. Bij de td-teksten waar nog niets mee is gebeurd in dhtml komen de getallen nog steeds wel in de msds maar zo gauw als het in dhtml is bewerkt niet meer. Wat gaat er fout of wat zie ik over het hoofd?

Voor wat betreft het afdrukken naar scherm van een msds heb ik ook nog een vraagje: sommige medewerkers zijn erg gewend om een afdruk naar scherm te maken (schrm/scr) en deze dan direct te lezen. Dat kan ook omdat er direct een kladblok wordt geopend met de msds. Op het moment dat je de instellingen wijzigt zodat je in html afdrukt dan moet je zelf het bestand opzoeken in je troep-directory. Is het niet mogelijk om de prfile.htm direct automatisch te openen?

Indien je bij een TD-Tekst welke een Standaard Element aanroept tevens tekst hebt opgenomen, wordt de waarde van Standaard Element niet afgedrukt in HTML.
Je zal deze TD-Teksten dus moeten splitsen: bij TD-Tekst 1 neem je de tekst op en je laat TD-Tekst 2 het Standaard Element aanroepen.

Dus voor elk standaard element moet je dan 2 td-teksten invoeren? Hoe krijg je die dan weer op 1 regel op de juiste plek?

Ja, maar dat stelt natuurlijk niets voor. Je tweede punt is vervelender: het is niet mogelijk om meerdere TD-Teksten achter elkaar af te drukken. En dus zal de waarde van een Standaard Element enkel onder de omschrijving van dat Standaard Element afgedrukt kunnen worden.

en dat kan niet worden aangepast?

Hmm... da's een lastige  :(

Als eerste "Ja, natuurlijk"
Als er een HTML document naar de printer gestuurd wordt, komt ze er op je printer uit, en print je deze naar een file, dan komt ze er in vorm van een PRFILE.HTM uit.
Dit betreft een vrij simpele aanpassing, waarmee ik er op één plek voor kan zorgen dat zodra er naar PRFILE.HTM is geprint, automatisch de Internet Explorer wordt opgestart om dat ding te bekijken.

Echter...

Met dat ik e.e.a. test, kom ik erachter dat het wel eens helemaal geen zin zal kunnen hebben een HTML pagina naar "het scherm" te printen...
Dit moet anders...

Nb: Bij een MSDS is "het probleem" overigens al wel opgelost, daarover zo meer.

Ik zal e.e.a. proberen uit te leggen (misschien wat technisch verhaal) met een voorbeeld + met een "bug" waarvan ik weet dat die nog eens opgelost moet worden:

De DHTML Editor is weliswaar de editor waarin we DHTML teksten intypen, maar de tekst die we maken wordt intern niet als HTML tekst bewaard. Intern wordt e.e.a. als MIME tekst opgeslagen, waarvan de HTML tekst een onderdeel is. Een MIME tekst mag je vergelijken met je Emails in Outlook (Express). Het betreft één bericht met daarin "alles" wat met de betreffende tekst te maken kan hebben. Zo zitten hier bijv. ook "attachments" bij.

Stel, je hebt een TD-Tekst. Je vult je tekst in middels de DHTML editor. In je tekst neem je een Image op (een gevarensymbool of i.d.), die verwijst naar bijv. G:\Images\Gevaar.bmp).
In je editor zie je netjes het plaatje staan. Als je de HTML coding zelf zou bekijken, dan zie je dat er gerefereerd wordt naar <IMG alt="" hspace=0 src="g:\Images\gevaar.bmp" >.

Helaas kunnen we met dié HTML tekst niet volstaan. Stel dat we de HTML tekst naar een klant sturen, dan zou bij hem géén Image getoond worden, immers "jouw klant heeft geen drive G: met een directory Images waar een file gevaar.bmp in staat". Bij het versturen van een email bericht wordt dan ook iedere verwijzing naar een plaatje omgezet naar "content" van het email bericht. Jouw plaatje wordt a.h.w. als een niet-zichtbare attachment opgenomen in het mailbericht, en je HTML tekst verwijst vervolgens niet meer naar g:\Images\gevaar.bmp maar naar de niet-zichtbare-attachment, ook wel "content" genoemd. Ieder plaatje krijgt zo zijn eigen "Content-Identifikatie" (CID afgekort).

NB: Als je bij een email naar "Bron" zou kijken, dan zie je daar ook deze CID referenties terug (als er plaatjes in je bericht staan).

Mooi. Precies datzelfde wordt ook toegepast bij de teksten die jij registreert. Op die manier wordt je image "gefixeerd" in het bericht. Desnoods gooit iemand het oorspronkelijk plaatje weg, ze is opgenomen als "content" van jouw tekst. Dit zorgt er ook voor dat jij een plaatje vanaf je lokale schijf kan opnemen, en dat deze vervolgens toch op een ander werkstation in de tekst gelezen kan worden; ze is nl. opgenomen in het bericht zelf.

Vervolgens gaan we e.d. bericht opvragen-/wijzigen. De oorspronkelijke lokatie van het plaatje is niet meer bekend, enkel "de naam" (gevaar.bmp). Ook al was de oorspronkelijke lokatie bekend, we zouden het plaatje nimmer mogen terugschrijven naar de lokatie vanwaaruit ze is opgenomen, immers daarmee zouden we wat anders overschrijven. Windows schrijft dit soort files dan weg in de "Temporary Internet Folder".

Nb: Maak maar eens een Word document, mail dat naar jezelf, open het geattachde Word document, en bekijk de bestandslocatie. Zoals je in File001 verderop ziet staat is dat in een tijdelijke folder opgeslagen.

Wij doen dit dus ook, maar dan in de \TROEP directory.

Als je vervolgens de HTML tekst opvraagt (lezen of wijzigen) dan zal alle content weer worden uitgepakt tot een file op disk. Niet in de "temporary internet files" directory, maar in \TROEP. Aldaar kun je konstateren dat er opnieuw een file "gevaar.bmp" wordt aangemaakt. Tevens verwijst je HTML tekst op dat moment naar "\TROEP\gevaar.bmp" opdat je het plaatje kunt zien.

Nou... op zich nog steeds geen probleem, en het printen zou nu ook nog steeds appeltje eitje moeten zijn, ze print gewoon o.b.v. \TROEP\gevaar.bmp.

Echter... en dat is "de bug": Als je nú een HTML tekst opvraagt blijft die uitgepakte content altijd in \TROEP staan. Ok, je kunt zelf die directory leegmaken wanneer je maar wilt, maar doe je dat niet, dan wordt die directory volgegooid met alle content die ooit uit dit soort MIME berichten tot stand is gekomen. Ofwel, maak je \TROEP directory leeg, vraag de TD-Tekst op, ga weer terug naar het Hoofdmenu, en tóch staat de file "gevaar.bmp" nog in je \TROEP directory.  Dit hoort natuurlijk niet, immers die \TROEP directory loopt hiervan langzaam vol.

Wat al enige tijd op de stapel ligt om opgelost te worden is dat dergelijke tijdelijk aangemaakte files automatisch weer verwijderd worden zodra je ze niet meer nodig hebt. Ofwel, tijdens de sessie dat je HTML document geopend is, heb je die files nodig, maar sluit je je document (omdat je op Escape drukt, of met F1 savet) dan kunnen ze verwijderd worden.

Vervolgens komen we ergens...

Als we de TD-Tekst zouden printen dan geldt:

a. openen DHTML tekst
b. content kopieren naar tijdelijke files op disk
c. printen document
d. verwijderen tijdelijk aangemaakte files

En we hebben een mooi printje met al onze plaatjes erop.

Maar nu doen we dit "naar het scherm".

a. openen DHTML tekst
b. content kopieren naar tijdelijke files op disk
c. printen document naar prfile.htm
d. verwijderen tijdelijk aangemaakte files
e. automatisch opstarten explorer om prfile.htm te bekijken

Op dit moment bevat je HTML tekst verwijzingen naar plaatjes die inmiddels verwijderd zijn !

Kortom, nú (omdat stap d., het verwijderen nog niet plaatsvindt) zou dit nog even werken, maar als dit probleem is opgelost, werkt het (dus) niet meer.

Merk ook op dat het juist om deze reden is dat bij het genereren van een MSDS de PRFILE.HTM "bijzaak" is. Je zou juist naar de PRFILE.MHT moeten kijken !

Stel dat jij een email bericht maakt, en de PRFILE.PRN als attachment naar iemand stuurt (buiten Profit om), dan ontvangt deze een HTML document waarin wordt gerefereerd aan plaatjes uit C:\TROEP. Nou, ga er maar vanuit dat die ontvanger niets ziet, want wederom geldt dat die plaatjes er niet zijn.

De PRFILE.MHT betreft echter een zgn. "Web-archief". Dit is een HTML document doch met de opmaak van een MIME bericht. Hierin zitten weer alle attachments, content etc. en dát document kun je wel naar iemand sturen.

Resumer: het bekijken van de PRFILE.HTM zal weinig zin hebben omdat erin aan temporary content wordt gerefereerd die er op dat moment niet meer hoeft te zijn.
Printen van een MSDS bevát al coding inzake het aanmaken van het Web-archief, en ik zal kijken of we daar dié versie niet meteen kunnen tonen.
Dan is je probleem opgelost, maar enkel "voor het MSDS", dus niet voor eventueel andere HTML documenten die je naar het scherm print.

De échte oplossing kon wel eens zijn dat "Printen naar het scherm" de PRFILE.MHT (Web-archief) moet aanmaken...

Dat is nu aangepast. Als het MSDS naar het scherm geprint is, wordt het opgebouwde webarchier daarna middels de explorer geopend.

Nb: In theorie kan het nu weer zo zijn dat jij liever geen explorer wenst te gebruiken, maar een andere browser zoals bijv. FireFox. Kunnen we ook wel weer wat voor maken, maar laat dát dan maar maatwerk zijn  :wink:

Oké, printen naar IE is prima aangezien dit toch op 99,9% van de computers is geïnstalleerd, het gaat er puur om dat de file geopend wordt. Is voor deze aanpassing een upgrade nodig?

Ja, inmiddels wel, omdat ik een bug in die explorer heb gevonden waardoor e.e.a. alsnog niet lekker werkt.

Kun je die upgrade vandaag al voor me klaar zetten? Dan ga ik die in het weekend installeren zodat we volgende week al kunnen testen.

Ik wacht liever even, want ik ben met nog meer MSDS zaken bezig, waarvoor e.e.a. wat drastischer op zijn kop gaat.

Zó belangrijk is dit het direkt bekijken in de explorer nu ook weer niet (toch?). Kun je (voor nu, tijdelijk) best even oplossen met een snelkoppeling naar c:\troep\prfile.mht op in je Windows Taakbalk.  :wink:

Oké, dat is inderdaad ook wel een oplossing voor eerst.

Dit probleem is inmiddels óók opgelost, zie Releasenote http://ha1.heartprofit.nl/profit/index.php?topic=21231.0

Kan helaas niet garanderen dat het op alle plekken zal zijn opgelost, omdat er honderden manier zijn om een stukkie tekst op je MSDS te krijgen. Ik heb i.i.g. getest met de produktomschrijving in hoofdstuk #1, alsmede met de eigenschappen in hoofdstuk #9. In beide gevallen kan ik nu met de DHTML editor de tekst vastleggen, en wordt de waarde van het Standaard Element achter aan die HTML tekst vastgeplakt. Het Standaard Element krijg op deze wijze ook dezelfde formattering zoals je met de tekst in je DHTML editor hebt vastgelegd.

Dit (http://ha1.heartprofit.nl/profit/index.php?topic=21231.0) was waar ik mee bezig was. Wat mij betreft zou je nu een Upgrade kunnen aanvragen.

Deze upgrade wil ik wel weer voor komende vrijdag gaan inplannen. Ik hoop wel dat dan de waarden ook worden getoond want dat krijg ik op dit moment helemaal niet voor elkaar (met 2 td-teksten ook niet).

Dat zei ik, dat kan ik je niet met 100% beloven, maar ik vermoed van wel. Bij mij doet ie het nu i.i.g. waar dat voorheen niet het geval was.

NB: Ik kan je nog wel proberen Profit-Base-Test aan te smeren ;-) Met die module heb je niet alleen Testbestanden, maar heb je in die Testbestanden ook nog eens de programmatuur gescheiden van Produktie. Op die manier zou je een Upgrade kunnen krijgen in je Testomgeving, terwijl produktie gewoon door kan werken op de oude manier. Pas als je de Upgrade zelf als "voldoet" betiteld, kun je besluiten de Upgrade van Test- om te zetten naar Produktie.

Aansluitend: Is het ook mogelijk om zelf een locatie te bepalen waar dergelijke bestanden worden opgeslagen zodat terug zoeken eenvoudiger word. Indien meerdere gebruikers bezig zijn bestaat nl. de kans dat het bestand wordt overschreven (en natuurlijk juist op een moment dat het niet uitkomt)

De \TROEP directory staat in principe op je lokale werkstation.
Mag op zich ook wel op het netwerk, maar dan "een plekje specifiek voor die user" (bijv. \USERDATA\WR\TROEP).
Een andere gebruiker kan dit niet zomaar even overschrijven; de gebruiker zelf wel.



Via de CONFIG.HRT kun je aangeven waar je Troepdirectory zich bevindt, en hoe deze moet heten.

Dit gaat in ons geval alleen op voor de gebruikers die via citrix inloggen op het systeem. Nu de MSDS automatisch wordt geopend kun je hem direct opslaan op een locatie van je eigen keuze.

De waarden bij de TD-teksten worden weer getoond dus vooralsnog lijkt het nu allemaal weer behoorlijk te werken!

Leuk dat je dat nog even laat weten.  :wink:

Het volgende probleem doet zich inmiddels voor: we hebben bij TD-teksten (1-1-7-5-3) de tekst-id 'RZO' geprobeerd aan te passen met de DHTML editor (dit is een TD-tekst waar alleen wordt verwezen naar het standaard element RZO). Dit is wel gelukt maar nu wordt er bij producten waar voorheen in rubriek 2 meerdere R-zinnen werden afgedrukt nu nog maar 1 R-zin afgedrukt. In rubriek 15 gaat het ook weer mis, daar wordt de eerste R-zin niet weergegeven maar de andere niet. Bijvoorbeeld C4P000212/B, bij dit product horen in rubrieken 2 en 15 de R-zinnen 10, 38 en 20/21 te staan. Als ik nu een nieuwe MSDS maak, dan komt in rubriek 2 alleen R10 en in rubriek 15 komen R38 en R20/21. Zien we iets over het hoofd of hebben we iets niet goed gedaan?

Kan hier nog even naar gekeken worden?

Overigens geldt bovenstaande ook voor de aanmaak en afdrukken van etiketten. Daar komen de zinnen ook niet op te staan.

De oplossing is waarschijnlijk : TD-Tekst 'RZO' verwijderen en opnieuw toevoegen (zonder tekst).
Als dit niet werkt, dan hoor ik het wel.

TD-Tekst is wat lastig te verwijderen. Eerst een melding over koppeling met een artikelgroep, deze hebben we verwijderd maar nu krijgen we nog een melding over koppeling met charge. Hoe kunnen we RZO alsnog verwijderen?

Niet. Even niet bij nagedacht dat je dit in een bestaande omgeving aan het wijzigen bent.

Probeer eens een nieuwe TD-Tekst te maken: RZONEW, waarbij je geen tekst opneemt en welke je laat verwijzen naar het Standaard Element RZO.
Koppel (in plaats van RZO) de TD-tekst RZONEW aan de betreffende Artikelgroep.

Gaat nog niet helemaal goed. Het lijkt wel of er automatisch een stukje tekst wordt gemaakt met deze inhoud (tabblad Bron):
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=ISO-8859-1" />
<META NAME ="GENERATOR" CONTENT="Heart-Profit for Windows">
<TITLE></TITLE>
</HEAD>
<BODY>
<DIV>&nbsp;</DIV>
</BODY>
</HTML>
Als ik dit stukje dan weer vervang door alleen "<div class=msds_tdr_text></div>" dan komt de eerste R-zin er weer op te staan maar de rest niet.

Je maakt de TD-teksten in HTML aan. De "bron"-tekst is hiervoor de basis. Kan Wouter je beter uitleggen, maar als je de melding krijgt "Waarschuwing: geen tekst ingevoerd" is het goed. Je moet de HTML code zeker niet gaan overschrijven.

Het Standaard Element RZO voegt tekst toe aan je MSDS. Het mechanisme anticipeert erop dat alleen die "bron"-tekst aanwezig is. Vandaar ook dat ik in eerste instantie vroeg om een nieuwe tekst aan te maken, omdat ik dan zeker weet dat die "bron"-tekst goed is (behalve als je die gaat overschrijven natuurlijk).

Het Standaard Element RZO haalt de R-Zinnen op en dat werkt al jaren goed. Als er nu een eerste tekst en/of een laatste tekst opeens niet afgedrukt worden, dan moet dat haast wel aan de HTML liggen. Dus bekijk van de MSDS die je hebt gemaakt de bron eens goed en misschien ontdek je daar wel iets vreemds aan. Je mag mij ook een kopietje mailen hoor.

Zelf een nieuwe TD-Tekst aangemaakt welke het Standaard Element 'RZO' aanroept. Bij deze TD-tekst géén tekst opgenomen en alle R-Zinnen worden gewoon getoond.

Even wat aanvullende uitleg, en dan wordt meteen een aanpassing die ik vandaag gedaan heb wat duidelijker.

Met de DOS editor was het mogelijk om een opgenomen tekst te verwijderen. Als je in de editor zat, haalde je alle tekst weg, savede dat, en vervolgens was er geen tekst meer opgenomen bij het TD document.

Met de DHTML editor was dat even wat lastiger, en betrof dit een puntje wat even op de langere baan is geschoven (maar sinds vandaag is opgelost). Ook al staat er geen tekst in je DHTML editor, dat houdt niet in dat je HTML document leeg is. Zo staat er minimaal altijd één <DIV> </DIV> in, wat ook  <P> </P> kan zijn of wat anders. Maar ook als je bijv. slechts een plaatje zou opnemen, dan heb je feitelijk geen tekst, maar ís het document niet leeg. Kortom, eenmaal een tekst opgenomen met de DHTML editor, dan kreeg je deze nooit meer weg. Hieruit vloeit Menno's eerdere opmerking uit voort: "verwijder die TD tekst, neem hem opnieuw op, en dan vooral geen tekst invullen".

Een echte oplossing is dat natuurlijk niet, want iemand hoeft de tekst maar één keer te wijzigen, desnoods omdat ze willen kijken of er tekst aanhangt, en omdat er geen specifieke weergeeffunktie is van de opgenomen tekst, en je hebt HTML tekst waar je niet meer vanaf kwam.

Per heden is er een oplossing, en wel als volgt:

Op Tab "Bewerken" geldt nog steeds dat het moeilijk te bepalen is of een tekst "leeg" is of niet. Maar als je naar Tab "Bron" gaat, dan krijg je daar je hele HTML coding te zien. Als je daar alle tekst verwijderd (met Control+A markeer je de hele tekst, gevolgd door delete) en dan savet, dan zal dit worden beschouwd als 'de eerder in de database opgenomen tekst moet worden verwijderd'.

Deze aanpassing vereist een nieuwe versie van de Systeemprocedure, en ik moet eerst intern wat overleg hebben omtrent het beschikbaarstellen van die procedure, omdat er wat meer mensen nu met Systeemprogrammatuur bezig zijn. Hoe dan ook, ik vermoed dat e.e.a. in ieder geval ergens volgende week zeker overgezonden kan worden. Tot dan geldt de escape van Menno (TD tekst verwijderen en opnieuw toevoegen).

Oké, dus dan is het in de toekomst weer gewoon mogelijk om zeg maar de wijziging ongedaan te maken, dat is nu wel wat onhandig inderdaad. Ik verneem dan wel wanneer dit gereed is.

Systeemprogrammatuur + Classes zijn beschikbaargesteld, dus als je wilt kan ik een Upgrade voor je klaarzetten.

Ik wil de upgrade weer gaan inplannen voor vrijdagavond/zaterdag dus als deze vrijdag klaar kan worden gezet zou dat heel mooi zijn.
:13c:

Reminder: kan de upgrade straks worden klaar gezet?

Goed dat je het zegt. Dank je.
:13c:

Upgrade staat voor je klaar

Het aanpassen van items in de msds gaat nu redelijk goed. Ik heb nog wel een vraagje: als je via 1-3-1-5 een msds maakt waarbij je een clientnummer invult dan komt de naam en het adres van de klant op de msds te staan. Kan dit ook uitgeschakeld worden, want het schijnt helemaal niet zo te mogen (bovendien hebben we liever een algemeen te gebruiken msds).

Als je nu gewoon de Kliënt-ident niet invult. Ben je er dan?

Nee, want dan kun je de msds niet registreren...

We maken het wel zo dat dit (ergens) een vast te leggen keuze wordt.
:13c:

Prima oplossing lijkt me maar dat was hoop ik wel duidelijk?

Nou, we waren hier aan toe, maar er lijkt toch iets niet te kloppen ...

Dat dit zo niet zou mogen twijfel ik al aan, maar, dat interesseert me verder niet veel; als jij dat niet erop wil hebben, dan komt het er niet op.
Maar er lijkt meer aan de hand;


en


plus


En hoe zie jij voor je dat je een algemene MSDS "registreert" dan ?
Ik denk dat je de algemene MSDS kan vergeten omdat het zo nu eenmaal niet in elkaar zit. Dit veranderen ? moet je vergeten. Zie overigens meerdere emails uit het verleden waarin ik heb aangegeven hoe een klant via een "webshop" alles tot zich zou kunnen krijgen, en waarbij het algemene aspekt feitelijk recht wordt gedaan (althans, als ik vermoed waar je heen wilt).

Goed. Waar bovenstaande dus niet gaat gebeuren, mag je van mij dus best die NAW eraf hebben. Maar weet je zeker dat dit handig is ? Ik denk, welk print middel je ook hateert, je weet niet meer wat voor wie is. Overigens los je dit met email wel op, maar ik geloof dat ik nog zit te wachten op de uitslag van die vergadering daarover ...

?

Voor wat betreft het niet af mogen drukken van de NAW gegevens zal ik navraag doen. Dat een MSDS algemeen bruikbaar wordt door geen NAW gegevens af te drukken is mooi meegenomen aangezien je zo'n MSDS dan zondermeer naar een contactpersoon kan versturen maar dat was niet de reden van dit verzoek. Het te versturen bestand blijft ook wel herkenbaar, aangezien de klient-id in de bestandsnaam zit (mht-file).

Een kontaktpersoon ?
Nou snap ik 'm helemaal niet meer. Of bedoel je toch gewoon "bedrijf" ?

Dat is meestal een bedrijf. Het komt ook wel eens voor dat een vertegenwoordiger een proef-hoeveelheid meeneemt voor een potentiele klant en daar hoort dan ook een MSDS bij mee te gaan, op papier. Dan is het wel makkelijk als je die gewoon kunt afdrukken zonder dat je rekening moet houden met eventuele NAW gegevens.

Ok prima. Maar dan moet je dus NIET registeren ...

Voor zover wij kunnen nagaan wordt er in publicaties zoals de VIB-gids exact aangegeven wat er in een MSDS moet staan. Hier wordt nergens gesproken over NAW-gegevens van de afnemer. Er wordt wel gesteld dat een MSDS voor elke afnemer gelijk moet zijn, wat strikt genomen wil zeggen dat de NAW-gegevens van de afnemer niet in het document zelf mag worden opgenomen. Dit komen we zelf in de praktijk ook altijd tegen: toegezonden veiligheidsbladen worden altijd voorzien van een voorblad of begeleidende brief waarop de NAW-gegevens van de afnemer staan.
Voor ons zou het een oplossing zijn als de MSDS kan worden afgedrukt, waarbij er wél geregistreerd kan worden, maar de NAW-gegevens van de afnemer niet op de MSDS zelf worden afgedrukt.

Als je het toch zo leuk vindt om hierop door te gaan ...


Het laatste bedenk je zelf op een wiskundige wijze en ik wil alvast met je wedden dat als je dit voorlegt aan een instantie die het echt zou moeten beoordelen (mocht je beschuldigd worden van iets) dat dit gewoon juist is.
En dan wil ik ook wel met je wedden dat wat je ermee wilt bereiken *on*juistheden uitlokt.

Van welke MSDS je ook wilt doen alsof ze algemeen is, ze is het niet (want je registreert), en dit is wiskundig onjuist.
Maar van mij mag je het hebben hoor : 3 uur.

N.b.: In de helptekst zal komen te staan dat het gebruik van de betreffende J/N niet conform de wettelijke regels is. Of het nu waar is of niet, wij zetten dat erin. Houd er verder (svp) rekening mee dat jouw .html met z'n unieke naam alleen voor jou geldt, èn alleen voor dit moment. Dus, zonder .html heb je dit helemaal niet, wat je moet vertellen dat wij niet gehouden zijn aan de handhaving van het "uniek maken op deze wijze" wanneer in later stadium andere oplossingen zijn gewenst - of komen.

Als laatste, technisch gezien is alles wat op het MSDS staat bijdragend aan het uniek zijn ervan (jaja, dat beoogt precies hetzelfde als wat jij denkt dat mag), met als gevolg dat ik niet kan overzien of het sowieso wel werkt. Ik dènk echter van niet. Voorbeeldje : het Artikelnummer is daar ook onderdeel van, en als je dat weg laat kan je twee precies dezelfde MSDSen hebben (puur toeval) maar weet het systeem niet meer dat er voor een ander Artikel toch echt weer een nieuw MSDS zal moeten uitkomen.
Moraal : die 3 uur kan je aan het weggooien zijn. Geen garantie, en uitzoeken doen we het ook niet. Immers, wij vinden dit onjuist.

Maar het mag nog steeds hoor ... :smile: :smile: :smile:

Nogmaals navraag gedaan bij VWA:
"het antwoord van de productdeskundige van de VWA
 
In bijlage II van de REACH verordening onder punt 1.3. 'Identificatie van de onderneming' staat: "Vermeld de identiteit van de persoon die verantwoordelijk is voor het in de handel brengen van de stof of het preparaat in de Gemeenschap, namelijk de fabrikant, importeur of distributeur. Vermeld zijn volledige adres en telefoonnummer ......". In titel IV atikel 31 van de verordening onder lid 1 staat: "De leverancier van een stof of preparaat verstrekt de afnemer van de stof of preparaat een overeenkomstig bijlage II opgestelde veiligheidsinfornmatieblad.....".
Volgens mij is het niet mogelijk dat de afnemer zijn adresgegevens gaat vermelden omdat de richtsnoer duidelijk spreekt van fabrikant, importeur of distributeur. "

Mogelijke oplossing staat inmiddels beschreven in topic: http://ha1.heartprofit.nl/profit/index.php?topic=21707.0