Heart-Profit ERP

Peter, zou je in deze topic zo af en toe aan willen geven wat jullie willen gaan aanpassen en wanneer je plant dit af te hebben.
Dan houden we een beetje de voorgang in de gaten

Peter,

Ik heb in het Chat deel van het forum een oproep gedaan naar de andere Heart users mbt GHS label printing.
Dit mede omdat het aan jullie kant erg stil blijft.

Hoever zijn jullie met de opzetten van de functionaliteit om OF de symbolen en RS zinnen van de WMS te tonen en printen OF om de symbolen en PH zinnen van de GHS/CLP te tonen en printen?

mvg

Marco

O jee, exkuses, maar ik heb de eerste post in dit topic echt nooit gezien !

Ok ... We hebben nog niet veel meer gedaan dan jij weet (wat feitelijk het belangrijkste deel is), met als doel het zo lang mogelijk kunnen "uitstellen" om achter definitieve beslissingen te komen. Je weet denk ik nog wel welke aanmerkingen ik zelf heb aangaande "onmogelijke" zaken, en ik wil niets voor niets doen.

Ik heb de hele tijd gedacht dat we er na de vakanties wel aan kunnen beginnen, maar denk op dit moment dat dit nog steeds onnodig te vroeg is.
Hiernaast wordt het wèl tijd om eens uit te werken hoe we met z'n allen nu denken om te gaan met twee systemen naast elkaar;
Voor mij is het goed als jij nog eens een voorzetje geeft (waarbij je wat mij betreft niet hoeft te denken aan mijn mitsen en maren), maar ik schiet gemakkelijker ergens op dan dat ik het verkeerd verzin. :smile:
Wil je dat doen ?
Kan wat mij betreft in dit topic.

Voor anderen : Als ik geen inmenging zie (afkeur noch goedkeur) dan heb je straks werkelijk pech als het "voor jou" anders blijkt te hebben gemoeten. Vergeet niet, het is voor jullie, en niet voor mij, en mijn advies is om er zeer serieus mee om te gaan, of anders kan je straks domweg niet meer opereren. Doe maar net zo serieus als Marco, dan komt het denk ik wel goed (Marco is nog 10 keer positiever dan ik, dus schroom niet om mee te denken !!).

Dank,
Peter

Luilak....

Maar OK, Ik zal beginnen met het opzetten van wat er minimaal in Heart aangepast moet worden.

Let wel: er moet een fundamentele keuze gemaakt worden hoe je om wenst te gaan met de data:

(1) Heart faciliterd alleen dat de gegevens (symbolen/P-zinnen/H-zinnen en EU zinnen) ingevoerd worden met de nodige vaste teksten per taal
(vergelijk huidige systeem onder 1.1.1.1.F2.J)

(2) Heart waagt de spring naar een SDS systeem met klassificatieregels en mogelijkheid deze per artikel aan te passen en te overrulen (regels zijn een stuk complexer geworden dan bij de WMS!!!)

Mijn persoonlijke insteek is gericht op (1) daar wij nu toch al draaien met chemges naast Heart.
Voor (2) kan ik wel een weekje cursus geven maar dat uurtarief zal denk ik niemand blij van worden (behalve ikzelf dan... :smile: :smile:)

Maar om voor de werknemer relevante informatie op bonnen te krijgen en om eventueel labels te kunnen maken is (1) voldoende.

Dus die keuze ligt eerst bij jou Peter.

En (1) hebben we al doorgesproken en kan ik zo in een documentje verwerken.

mvg

Marco

Eerste stukje, zo even uit de losse pols

Optie 1:

Binnen de EU komen er nu nieuwe zinnen en symbolen tevoorschijn.
Er kan hier gebruik gemaakt worden van dezelfde functionaliteit als die in Heart al aanwezig is onder functiepas 1.1.1.1.F2.J

Dit vereist wel een paar aanpassingen:

Nieuwe zinnen

Tabel LORS heeft een extra indicator veld nodig voor keuze WMS/GHS om de zaken goed gescheiden te houden.
Ook hieraan gekoppelde bestanden zoals LORA zullen deze indicator moeten volgen.

Immers in de periode 2010-2017 kunnen beide wijzen van labelling toegepast worden.

Key van de H-zinnen moet > 12 zijn
Key van de P-zinnen moet > 18 zijn

Conclusie key moet op 20 gezet worden, is nu 12 posities, dus moet aangepast worden.
Daarnaast moet invoermasker op alle schermen de nieuwe indicator respecteren en moet het masker de P, EU en H prefix accepteren. (is nu alleen R, S en P)

Voor wat betreft de print variabelen moeten alle RS variabelen gedubbeld worden naar de nieuwe waarbij de volgorde moet zijn H, EU en dan P.

Nieuwe symbolen

Ook hier moet een indicator gemaakt worden om de oude  en nieuwe wet te kunnen scheiden.
Lengte van het nieuwe keyveld = 5 posities, dus dit veld moet met 2 posities uitgebreid worden
Voor wat betreft print variabelen moeten deze dus ook beschikbaar komen.

Artikelniveau

Op artikelniveau moet ook een indicator komen om aan te geven of een item volgens de oude of de nieuwe wet gelabeld dient te worden.

Daar zit nog een probleem.
Momenteel overstijgt debiteur label format het artikel niveau.
Mijn inziens is dat voorlopig alleen op te lossen door de trigger bij artikel te plaatsen en dan bij debiteur 2 labelformats op te kunnen geven.

Zelfde geldt voor in ons geval de print productieorder.
Ook deze moet op basis van de artikeltrigger de oude c.q. nieuwe gekoppelde zinnen en symbolen geven.

Wat blijft er dan nog over:

Er zijn nog teksten die geen nummer hebben maar wel verplicht kunnen zijn. Daar moeten we een oplossing voor vinden.
Misschien een T-code erbij of zo, moet in ieder geval nog opgelost worden
Daarnaast eist de nieuwe wetgeving dat alle teksten die veiligheid relevant zijn ook in alle talen beschikbaar gesteld worden op een label van de talen van de H zinnen op het label.
Dus daar moet gewerkyt worden met taalafhankelijke artikelteksten.


MSDS berekenen

Wel of niet dat is de vraag….



Operationeel technisch:

De nieuwe pictogrammen zijn 2 kleuren (rood zwart).
Lege diamanten zijn niet toegestaan.

Opties:
(1)   Print zwarte diamant over voorbedrukte rode (lege) diamand.
(2)   Print in kleur (Dit vereist een goede kleurenprinter driver en wat support van Heart om draaiend te krijgen in PCL of Postscript)
(3)   Maak voor elk aantal rode diamanten een voorbedrukte labelstock
(4)   Zie mijn post voor de chemges gebruikers

Geweldig zo ver.

Voor de zekerheid toch de vraag : betrof dit een expliciet denken aan twee systeem naast -/door elkaar ?
Immers, dit is wat ik het minst zie zitten.

Dank.

Ja,

Wetgeving is opgebouwd in termijnen:

CLP labels op grondstoffen en eindproducten (mengsels) mag sinds vorig jaar

Op grondstoffen en in de wet vermelde mengsels eind dit jaar verplicht, uitgezonderd een uitverkooptermijn van 2 jaar voor de goederen die al in de handel zijn gebracht.

In 2015 moeten ook alle mengsels CLP labels krijgen
Ook dan weer diezelfde 2 jaar uitverkooptermijn voor goederen welke al in de handel zijn gebracht.

Dus in 2017 moet alles CLP gelabeld zijn.

PS
Je mag NOOIT beide labels op 1 verpakking aanbrengen!


Voor MSDS geldt trouwens dat alle grondstoffen t/m 2015 beide klasseringen moeten tonen (ook al ben jij over jouw klant die het weer in een mengsel gooit mag de oude klassering tot 2015 blijven voeren en jij moet zeggen wat die indeling volgens de oude klassering is.)

Ok. Alleen ik zie het niet helemaal terug. Tenminste, niet voor de essenties die ik in theorie zie.

Denk aan de registratie van inkomende produkten/MSDSen, idem voor je eigen produktie en hoe we dan de output dubbel en op twee manieren maken, je eigen halffabrikaat wat op twee manieren input is naar je eindprodukt, je CASnr registratie definities.

Begin maar met te denken dat je bovenstaande allemaal dubbel moet gaan doen terwijl je het voor de GHS allemaal nog lang niet weet.

Gaan we dit inderdaad allemaal dubbel definiëren en bijhouden, of gaan we iets verzinnen waardoor de GHS wel voldoende is ?
Her eerste mag, maar ik weet niet hoe.
Het tweede mag niet, maar ik weet vast wel hoe.

En nu ?

Vergeet vooral niet dat als je "nu" een oude methode MSDS krijgt toegeworpen, dat je deze zelf mag omzetten naar GHS. Of ga je wachten tot iedereen dat aanlevert in 2011 ?

Volgens mij kan je nog het beste vervroegd pensioen aanvragen, met verlaagd salaris. Kan je altijd nog cursussen geven in hoe het niet moet/wrkt.

Hoe dan ook, en nu ?

Ook wij zijn erg geïnteresseerd in de implementatie van CLP.
Maar aangezien wij geen stoffen verkopen, maar alleen mengsels, hoeven wij pas per 2015 de etiketten en MSDS-en omgeschakeld te hebben op CLP.
Wat op dit moment actueler is voor ons, is de wijziging van de Annex II van REACH, waarin o.a. staat dat ook symbolen (dus niet alleen de tekst van een symbool, zoals nu het geval is) moeten worden geprint op een MSDS (nu nog in rubriek 15, maar vanaf december in rubriek 2). Dit mag overigens gewoon in zwart-wit.
Graag vernemen wij of jullie hier al mee bezig zijn.

Vrgr

paul

Iedereen die een stof maakt c.q. importeerd in de EU is vanuit REACH verplicht om eind dit jaar die stof met labelingsvoorschrift aan te melden bij de C&L Database (Classification en Labelling)
Iedereen weet dan hoe een stof gekenmerkt moet worden.

http://echa.europa.eu/clp/inventory_notification_en.asp

Dat een ieder niet blij wordt van een transitie periode van 7 jaar is duidelijk.
Echter deze is bijna 1:1 gekoppeld aan de eisen van de REACH beoordelingen (lopen ook in 2015 af !)

Vandaar deze spagaat in wetgeving


Pwoelders is trouwens niet correct:
Ook de AI vraagt de CLP labnelling voor stoffen op jouw terrein en ik weet zeker dat je dan wel mengsels verkoopt, maar de regels gaan ook op voor jouw mensen en op een productieorder zul je dadelijk dus R10 krijgen voor een mengsel dat jij als grondstof inzet, maar voor een pure stof moet je dus de H-zin gaan communiceren naar jouw mensen.
Ook moet de leiding markering e.d. aangepast worden naar CLP en ADR. enz. enz.
We praten hier niet alleen over de kant van de klant maar ook over jouw verantwoording als werkgever.

Er verandert nog wel wat meer in de SDS.
In de nieuwe wettekst staat namelijk op veel plekken nu nog "can" en dat is op de meeste plaatsen vervangen door "shall".
Dus waar je voorheen bij een rubriek in de SDS aangaf : n/a mag dit veelal neit meer tenzij je daarbij een motivatie geeft waarom niet.
Je krijgt ook hier nog aardig wat voor jouw kiezen....

Maar als je daar meer over wilt discussieren kun je beter een aparte tread openen in de MSDS sectie.

Hier beperk ik me liever tot de schermen en tabellen structuur van Heart.
De uitwerking naar een nieuwe stijl MSDS is een veel breder verhaal.

Heren, maar dames ook hoor :smile: ...

Ik kan me voorstellen dat niet iedereen het forum leest (sterker, de meesten doen dat niet, en klagen tegelijkertijd dat ze nooit eens iets horen), maar met het hoofd in het zand steken gaan we er niet komen. Gewoon, omdat *wij* het niet zien zitten.
Lees desnoods nog even enkele posts terug, waar bovenstaande quote uit komt.

Ik neig naar het volgende :

Eenieder die helemaal zelfstandig in Profit z'n MSDSen regelt (en dat zijn er niet zo heel veel meer volgens mij), weet volgens mij niet waar die blijft als e.e.a. zodirekt dubbel moet gaan gebeuren. Dit geldt al voldoende voor de nieuwe GHS denk ik, laat staan dat je e.e.a. ook nog zo in elkaar moet gaan draaien dat het voor twee systemen tegelijk geldt.

Technisch (maar dat is nauwelijks "funktioneel" te noemen) kunnen we iets maken wat in twee bedrijven opereert, waarbij je (met de betreffende additionele funktionaliteit) twee totaal verschillende strukturen opzet, opdat technisch gezien alles uit elkaar te houden is. En let wel, dit betreft meteen ook "funktioneel uit elkaar houden", want als je voor een produkt een twee Stuklijsten nodig zou hebben voor de verschillende situaties, dan kan je dit dus regelen.
Maar niemand gaat in twee administraties zaken dubbel bijhouden, lijkt me toch ...

Als wij in de database al dit soort zaken zo zouden moeten opzetten dat alles dubbel kan worden geregistreerd en bijgehouden ... vergeet het gerust. En anders, wie betaalt ons de maanden werk dat dit zal vergen ?
Hierbij hoop ik dat het duidelijk is dat wij dit niet zullen bekostigen.

Dit laatste geldt al in zijn algemeenheid, dus denkend aan wat er normaal zou moeten gebeuren om alles voor de GHS werkend te krijgen. Echter, dit is te overzien, en als iedereen 1000-2000 euri zou moeten bijdragen hieraan, dan komt dat heus wel goed.

Wat het voor ons (op dit moment) lastig maakt, is dat we óók niet kunnen overzien wat e.e.a. uitmaakt als je bijvoorbeeld Chemges gebruikt.


Mij zegt dit dat je in elk geval de gegevens van de MSDS van een derde (inkoop) niet hoeft bij te houden. Immers, die kunnen uit die database komen, en via Chemges zal je er wel een MSDS van kunnen maken. Dit leidt er m.i. toe dat je het zelf niet meer moet *willen* doen, en wat volgens mij ook voor je eigen produkt(ie) geldt.

Ik denk -maar nu gaat me de inhoudelijke pakketkennis ontbreken- dat e.e.a. net zo goed geldt voor de af te drukken symbolen. Dus, als je alles binnen Profit op orde hebt komen ze daar vandaan, en als je alles half op orde hebt ook nog wel. Maar als je zodirekt twee kanten op moet kunnen (oud vs nieuw) dan *kan* je het niet meer op orde hebben voor oud of nieuw (dus, nooit tegelijk), en kan je maar beter aan Chemges vragen welk etiket je moet afdrukken. Let wel, volgens mij gebeurt dat ook op deze manier (hier en daar), maar vraag mij niet a. hoe dynamisch Chemges hierin is (je moet oud of nieuw kunnen vragen) en b. in welke mate je alsnog in Profit zaken dubbel moet bijhouden wil e.e.a. kunnen werken.


Dus, samengevat voor dit moment, de GHS is het probleem niet, en dat kan worden gemaakt;
Hoe e.e.a. samen met de oude methode moet worden geregistreerd (door jullie) is mij totaal onduidelijk en zie ik NIET zitten.
En dus heeft het geen zin om ook maar iets aan GHS te doen, waar wij het zouden moeten bekostigen, en zonder te weten of het nut heeft.

Ik zie tot op heden niemand reageren op "mijn" problematiek; ook Marco niet. Dit is misschien logisch omdat het feitelijk jullie werk niet is. Maar ik zou toch wel erg graag duidelijk willen maken dat *ik* niet zie hoe e.e.a. op te zetten, waarna jullie toch zelf echt het probleem zullen hebben. Ofwel :
Jullie kennen allemaal Profit, en als je je werk doet heb je je ingeleefd in de problematiek van het "x jaar twee systemen moeten voeren". De hele wereld heeft kennelijk Ja en Amen gezegd tegen dit soort idioterie, maar dat houdt nog niet in dat wij verantwoordelijk zijn voor de oplossing, als er al nulkommanadaniemand is die hier met ideeën komt. En heeft niemand een idee ? ook goed, maar het is nog steeds niet onze verantwoordelijkheid.

Ik zal eenieder die hierbij feitelijk betrokken is een email sturen, zodat niemand het heeft gemist dat wij niet weten wat te doen. Voor de helft weet ik nu al dat die WEL het forum lezen, maar doodleuk afwachten wat anderen doen. Doodleuk ?
Ik heb het al eerder gezegd : alleen Marco lijkt zich voor z'n eigen hachje in te zetten, en deelt dat nog met jullie ook.
Kunnen we nu alsjeblieft onze verantwoordelijkheid gaan voelen ?

Hartelijk dank.
Peter

Even heel duidelijk:

DE Heart-Profit SDS module heb ik dus helemaal laten varen, gebruik eigenlijk alleen nog de functionaliteit om vrachtbrieven met goede Proper shipping name e.d. te genereren

Alle andere gegevens in Heart haal ik uit de vaste tabellen en koppel deze binnen heart dus zelf op artikelniveau (oftewel artikeleigenschappen zelf en sectie [J] onder het artikelmenu)

Omdat we echter deze data ooik gebruiken op onze productieorders ivm de verplichte communicatie van de gevaren van de stoffen waarmee onze werknemers werken en de huidige RS labels ook direct vanuit heart genereren wil ik dus de GHS pictogrammen en zinnen ook binnen heart kunnen aangeven gelijk ik nu onder de sectie [J] van het artikel doe, zodat ik deze zaken nog steeds kan blijven gebruiken voor mijn wettelijk verplichte interne instructie van mijn werknemers.

Het idee om GHS labels vanuit heart te kunnen genereren heb ik eprsoonlijk al losgelatren en ik zal dan ook een interface laten maken die de nodige velden vanuit heart naar een file zet (zit al in heart gaf Robert aan)
en dan een inlees en printmodule bij chemges gebruiken om daar de labels te genereren naar een kleurenprinter (kosten maatwerk software ca. € 3000).

Maar Peter heeft verder wel gelijk: Wie gaat er verder nog wat doen en wie laat wat van zich horen!!!!!!

Wij gaan de MSDSen en labels ook buiten Heart regelen. We hebben echter nog niet besproken hoe we de informatie intern (productieorders ed) willen gaan zien. Dat moet nog gebeuren.
Op dit moment nog geen ideeën dus.


Groeten,
Cathelijn
SE

Toch Catelijn moeten we hierover eens worden.
AD is net als Spectro een club met veel chemicalien en we moeten wel een werkbare situatie houden.

PS gaan jullie ook via chemges werken of gaan jullie naar een andere oplossing?

Je hebt helemaal gelijk. Nu in de vakantietijd is het lastig om dit snel op de agenda te krijgen, zelfs als het prioriteit heeft.
Ik hoop daarover begin volgende week even van gedachten te kunnen wisselen met René.

En nee, wij hebben niet voor Chemges gekozen.

Zoals gemeld Peter: Ik hoop dat je er wat mee doet/gedaan hebt

Dank je voor je reaktie Marco.

Even een quote uit dat andere topic, dan hebben we het hier weer een beetje bij elkaar :


en nog even een quote van mezelf, eerder uit dit topic :


Ik kan me (intussen) wel voorstellen dat het "niets" is om dit via wat forum communicatie te laten verlopen, en misschien had ik het bovenstaande ook wel vet/groot moeten afdrukken, maar ik zie in elk geval nergens een (aangedragen) oplossing hiervoor. Dus, jouw "Blijft over in Profit" is kwa essentie wel duidelijk, maar (voor mij) ook niet meer dan dat. Dus, probeer je voor te stellen dat ik al nooit kan weten wat je precies bedoelt, omdat dit "eigen inrichting" betreft (tenminste, dat zou ik denken).

Om jou te helpen met meedenken, doen we het eens even andersom; en let wel, je hebt één database, gebruikt wat mij betreft ook één administratief bedrijf hiervoor (twee lijkt me niet te doen voor jou/jullie), je hebt P-zinnen die wat mij betreft naast de R&S zinnen kunnen bestaan (en dat heb je al), maar je hebt dus geen enkele mogelijkheid om twee sets "reglement" te beheren. Dus kijk naar je kantelpunten, en zie onmiddellijk dat je die niet uniek kan maken naar "oud" en "nieuw". Heb je die Kantelpunten niet nodig ? mooi, dan levert dat dus geen probleem op (maar begrijp dat er ook geen berekening meer uit komt - dan).


Kan je hier leven met alleen de nieuwe methode ? -> geen probleem.


Dit klinkt niet best, want waar we op weg zijn naar de nieuwe methode, riekt dit dus naar het gebruik van zowel oud als nieuw.
Op zich mag dit nog net, *mits* je twee sets van de hele handel weet te kreëren, *plus* dat je die sets beiden moet kunnen koppelen "aan" (aan wat ?) en ergens moet kunnen aansturen.
Graag jou visie hierover, want ik zie het niet (zitten).


Nieuw dan maar ?


Zelfde problematiek;
Denk ik deze in de richting van : een symbool kan een aanduiding Oud en Nieuw hebben, en aan een Zin kunnen zowel (herkenbaar) Oude en Nieuwe worden gekoppeld. Echter, de Zin zelf weet van niets (of ze Oud of Nieuw is), *tenzij* je twee sets weet te maken en een attribuut dit kan aangeven (niet de sleutel dus). Dus, iedere Zin weet dan van zichzelf of ze Oud of Nieuw is.


Dan nog voor de duidelijkheid, opdat je weet hoe serieus ik ben :
Als je wat dan ook met een produkt moet doen -en denk maar even aan een grondstof- dan heeft dit van zichzelf al R&Z&P zinnen, maar Oud of Nieuw en met pech beiden. Een andere grondstof heeft Nieuw waar de eerste Oud heeft, en ...
Voel je ? hier stop ik gewoon met denken. Alles hangt namelijk af van wat je waar nodig hebt, en of het bruikbaar zal zijn.

Zolang er niemand is die mij vertelt hoe je met Oud en Nieuw kan omgaan, gebeurt er dus niets (want wij weten gewoon niet wat we moeten doen). Daaraan is in (intussen) al die tijd niets aan veranderd.

Peter


PS:
Hier mag je mee even mee helpen (weet ik niet meer).

Het hoofd blijft dus in het zand zitten ?

nee hoor, zal het voorstel tikken

maar moet wel weten of ik rekening moet houden met klanten die "nog wel" met de Heart SDS module werken of niet

zo niet doe ik het op basis zoals Wij ermee omgaan en dat is onder artikelmenu optie J-1, J-2 en J-3 als "informatiebronnen" toe te passen en die op diverse plekken te tonen (zoals op de productieorder)

Dus wie er nog wel met Heart SDS werken, dat kan ik niet zien??

Ah, geweldig Marco !


Probeer je maar eens voor te stellen wat ik nu *eigenlijk* aan jou vraag ... Dat is namelijk 100% hetzelfde. IK WEET HET NIET, maar de mensen weten het zelf niet eens. Neem als voorbeeld een bedrijf uit Alphen en je weet ook weer wat ik daarmee bedoel. Het is een aardig kip-ei verhaal aan het worden - voor iedereen even moeilijk en moeizaam, en waarbij jij intussen de verantwoordelijkheid lijkt te krijgen (jawel, door mij gegeven, want wij weten dus eigenlijk helemáál niets -> ik heb het niet over de technische aspekten, maar over het gebruik en dan 100% geënt op de twee manieren tegelijk).

En nog even voor jou informatie - maar meer het begrip van de moeilijkheden : de mensen uit Alphen komen doodleuk thuis met de mededeling "ok, we kunnen het beter zoals AD gaan doen, maar over een klein jaar pas" (het is nu te laat, zeg maar), en of we alsnog hetgeen willen maken waarvan ik niet weet hoe het moet. Ik zou zeggen : bel die eerst nog eens op als je wilt, want het komt gewoon niet goed zo.

Een jaar geleden riep ik alleen maar "help" voor de technische kant van de zaak. Maar sinds een half jaar roep ik "help" voor het hoe dan ?.
Eens moet er een eerste keer zijn dat wij niet weten hoe iets te realiseren. Ik denk dat dit nu is ...

Peter

Ik heb met diverse partijen gesproken en Alphen wil inderdaad door met Heart totdat zij intern klaar zijn en schatten dat dit een jaar duurt.
Oss gaat zeer waarschijnlijk net als AD naar een extern pakket met interface.

En wat ik wil weet je.
Is het mogelijk om de data onder artikelmenu J1, J2 en J3 te gebruiken zonder dat dit de SDS'sen van de anderen sloopt?
ik wil echt deze punten realiseren:
- R&S en H&P zinnen tbv informatie op labels oude stijl
- R&S en H&P zinnen tbv informatie op productieorder
- oude en nieuwe symbolen aanduideingen voor beide bovenstaande punten

Daranaast blijft het stukje vrachtbrieven met de daarbij behorende wetsaanpassingen elke 2 jaar gewoon terug komen.
Voor dit jaar is dat dit maal niet zoveel.
Zodra ik van VROM uitsluitsel op 2 vragen heb gehad zal ik wel een voorstel schrijven.

Het gaat namelijk alleen om wat kleinere tekstaanpassingen

Marco, aangaande wie wacht op wie ...


?

Helemaal mee eens:

Helaas krijg ik van de anderen geen feed-back, dus dan moet ik zelf er maar naar kijken...
helaas

PS

ADR en REACH aanpassingen gaan in separaat item om "verwarring"  te voorkomen

Heart aanpassingen mbt CLP

Let wel deze aanpassingen worden alleen aangevraagd om op de productieorder de benodigde CLP elementen weer te geven, met behoud van de DPD (WMS) label print functionaliteit.
Het betreft géén herschrijven van de SDS functionaliteit, hoewel deze hier wel “inpast”


Aan te passen tabellen:

LOGE
-   Invoegen CLP/DPD indicator
-   Gevarensymbool uitbreiden naar 5 karakters, CLP gebruikt gebruikt GHS01, GHS02 enz.

LOGO
-   Hier niet van invloed

LORS
-   Masker op Id uitbreiden naar H en P zinnen
-   P zin bestond ook al in DPD dus opppassen
-   Invoegen CLP/DPD indicator
-   Verdere functionaliteit gelijk
-   Voorbeeld combo zin wordt P371+P380+P375 dat betekent Id van minimaal 11 karakters

LOGS
-   Voor mij niet nodig, maar voor wie de SDS nog verder wil gebruiken: toevoegen REACH Id (dat is zonder de 4 laatste cijfers die de bron aangeven), opbouw voorbeeld chroomzuur 01-2119458868-17



En dan moeten dus alle afgeleide functies en printvariabelen hierop aangepast worden

Wat mij betreft wordt in de schermen de CLP/DPGD indicator als 1e sortering gebruikt zodat de items “per wet” gepresenteerd worden, met eerst de DPD en dan de CLP informatie
Kan middels keuze voor boolean op indicator. (0/1 of J/N vinkje)


Voor wat AD wil is dat beperkt tot de toevoeg/wijzig en raadpleegfuncties onder J1, J2 en J3 van het artikel menu en dadelijk de representatie op de productieorder.
En ervoor zorgen dat de huidige RS variableen en label variabelen die in de variable layouts etiket worden gebruikt de CLP/DPD indicator respecteren


Voor onze vrienden uit alphen gaat dit echter een puist meer werk vergen

:yahoo::yahoo::yahoo:

Nou, dan gaan we dàt maar eens doen.

Nog een vraag, voor het geval ik het toch nog verkeerd begrijp :


Aannemend dat iemand (zoals zij) voorlopig zonder de GHS kan, is dat dan wel juist ?
(ik bedoel eigenlijk : ik zie het even niet)

Harrrrtelijk dank.

per 1 december is GHS label verplicht voor enkelvoudige stoffen (grondstoffen) die je op de markt brengt en voor stoffen die in de Annex-1 met nota A vermeld staan (dat is ...% achter de naam in de tabel)

Voor die stoffen moet in het SDS zowel de DPD als de GHS indeling vermeld staan.

Wij voeren de stoffen wel in onze verkoop, over anderen kan ik niet oordelen

De oude P-Zin is destijds ontwikkeld t.b.v. "Special Product Phrases". P-Zinnen zijn niet formeel, en de letter P hebben we destijds zelf verzonnen bedoeld als "Produktzin".

Om "ruimte vrij te maken" voor de nieuwe P-Zin (Prevention, vergelijkbaar met de oude S-Zin), zullen de oude P-Zinnen worden omgenummerd naar T-Zinnen (T = Tekst).

Het middels een konversie omnummeren van de oude P-Zinnen naar T-Zinnen zal wat mij betreft de 1e stap zijn in de aanpassingen in deze hoek. Het zal (mij) tevens een idee geven waar de R-S-P-Zinnen allemaal toegepast worden. Zodra we eenmaal beginnen met sleutelvelden te wijzigen (uit te breiden van 12 naar 20 chars), zullen we even geen Upgrades meer kunnen genereren totdat alle programmatuur in deze klaar is.

Deze aanpassing is klaar. Bij de eerst volgende Upgrade worden P-Zinnen gekonverteerd naar T-Zinnen.
Zie Releasenote http://ha1.heartprofit.nl/profit/index.php?topic=23076.0

Off topic is inmiddels bepaald dat het uitbreiden van de sleutel niet meer aan de orde is. De langste zin is de kombinatie P-Zin in het voorbeeld van mdekraa "P371+P380+P375" en zou 14 posities betreffen. Deze zinnen kunnen we ook best definiëren als "P371+380+375" of als "P371/380/375" in welk geval de huidige 12 posities gewoon voldoen.

Merk op dat bij de oude P-Zinnen (nu T-Zinnen) ook dergelijke kombinaties bestonden, en zonder herhaling van de P werden opgenomen. Zo ook kombinatie R-Zinnen, die genoteerd worden als "R21/22/23" en niet R21/R22/R23".

Het uitbreiden van diverse sleutels (R&S Zinnen, Eigenschappen, Tekstbestanden, alles op Taal etc.) is dan niet meer aan de orde, en daarmee is ook een status van "even geen upgrades genereren" (tot dat alles weer één consistent geheel is) van de baan.

Is inmiddels voor iemand anders ontwikkeld. Zie http://ha1.heartprofit.nl/profit/index.php?topic=23069.0

Na het omzetten van de oude P-Zinnen naar T-Zinnen zit ik er wat dieper in.

Meteen nog een paar vragen. Ik probeerde je (mobiel) te bellen, maar je bent er niet, dus bij deze maar even via het forum:

Je hebt telefonisch al toegelicht dat jij het zo voor je zag dat de CLP/DPD indikator in de sleutel zou worden opgenomen. Dat gebeurt niet (lees: veel te veel werk). Maar... ervanuitgaande dat dat niet gebeurd... heb je die indikator dan eigenlijk nog wel ergens voor nodig ?

Natuurlijk is die indikator in zoverre handig dat het pakket op deze manier "weet" dat R&S zinnen bij elkaar horen, en dat H&P zinnen bij elkaar horen. Maar hebben we dat überhaupt ergens nodig?

Het eerste wat ik voor me zien als ik die indikator ga opnemen, is dat deze altijd gedisabled op het scherm staat, immers, als je een R&S zin toevoegt moet die indikator de "WMS" situatie impliceren, en als je H&P toevoegt, zal het "CLP" moeten impliceren.

Alles sorteren op "oude-/nieuwe wetgeving"; leuk, maar ik denk niet onoverkomelijk. Ik bedoel, als e.e.a. op Identifikatie gesorteerd is, heb je nog steeds alle R-Zinnen, alle S-Zinnen, alle H-Zinnen en alle P-Zinnen bij elkaar; daar voegt een sortering op wet weinig aan toe.

Kijkend naar je gevaren-etiketten, dan heten die in de nieuwe situatie allen GHSxx, dus ook die herken je vast wel zonder dat e.e.a. op wet gesorteerd is.

Dan even naar "waar gaan we dit daadwerkelijk gebruiken" in het systeem?

Je Etiketten en je Produktieorder.

Ok... Laten we eens beginnen met je Produktieorder...

Wat is daar precies de bedoeling? Dat je bij het opstarten van de P.O. Print moet kunnen aangeven "ik wil H&P zinnen hebben en niet de R&S zinnen"? En, zo je e.d. indikator nodig hebt, wat bepaalt dat dan? Vast niet de persoon die dat printje opstart, maar ik denk eerder het produkt, welke je al op de nieuwe manier hebt ingericht of zo, en zolang dat nog niet het geval is, moet het op de oude manier.
Waar ik naartoe wil is dat je het met een J/N rubriekje w.s. niet gaat redden, al was het maar omdat je P.O. 201011260001 t/m 201011269999 afdrukt, en de ene PO met R&S zinnen moet worden afgedrukt en de ander met H&P zinnen.

Dan je Etiket. Daarvan schrijf je dat deze de CLP/DPD indikator moet respekteren. Aha... Maar zo'n Layoutvariabele verwijst bijv. naar TDORS (Technisch Document, Omschrijving R-Zin), en tsja... een R-Zin impliceert nu eenmaal de oude manier (indikator of niet).

Nu ik wat met Standaard Elementen in het MSDS te maken heb gehad, lijkt me dat daar de oplossing in zit.
Om R-Zinnen op het MSDS te tonen hebben we een Standaard Element "RZO" (= Identifikatie + Omschrijving) en "ORZ" (enkel de omschrijving van de P-Zin). Op dezelfde wijze hebben we ook een RSO/ORS voor een S-Zin, en een RTO/ORT voor een T-Zin. Die zelfde Standaard Elementen zijn momenteel de basis voor jouw Layoutvariabelen voor je etiket. O.b.v. de ORZ/ORS/ORT worden de TDORZ/TDORS/TDORT variabelen gegenereerd.

Volgens mij komt het er nu gewoon op neer dat we nu 2 (x2) nieuwe Standaard Elementen nodig hebben voor de H&P zinnen, RPO/ORP en RHO/ORH. Hieruit worden vervolgens TDORP/TDORH variabelen gegenereerd. Vervolgens hebben we niets te maken met een indikator oud/nieuw in Profit, maar jij hebt gewoon 2 verschillende Etiketlayouts: eentje conform WMS die refereert aan ORZ/ORS/ORT variabelen, en een CLP etiket die refereert aan ORP/ORH variabelen.

Grappige is dan trouwens ook dat de liefhebber een MSDS in elkaar kan schroeven die niet refereert aan het Standaard Element RZO/ORZ maar RHO/ORH en je hebt ineens een document met Hazard codes erop i.p.v. Risk codes.

Sla ik de plank raak? of juist helemaal mis?

Afgelopen vrijdag dit topic nog tel. met mdekraa besproken. Het lijkt erop dat we op deze manier fexibel zijn en zelf kunnen bepalen wat we wel/niet op het etiket willen hebben (waarbij beide ook mogelijk is, hooguit formeel niet wenselijk).

Is nu ook klaar.

De definitie van een Etiket Layout bepaalt straks of het een WMS danwel een CLP Etiket betreft. Geen indikator bij het Etiket, maar gewoon iets wat "layouttechnisch" wordt bepaald (en in de omschrijving v/h etiket dient te worden opgenomen).

Onder de huidige set layoutvariabelen worden de Gevaren Etiketten van WMS weergegeven; voor CLP (of voor de situatie dat je beide wenst af te drukken) zijn er nieuwe variabelen ontwikkeld.

Zie verder http://ha1.heartprofit.nl/profit/index.php?topic=23087.0

Wouter,

met betrekking tot jouw overzicht van vrijdag: helemaal accoord incl. de zaken die we hebben besproken (terwijl ik in madurodam stond en jij met autopanne thuis)

Graag wil ik wel op artikelniveau een indicator, maar meer om aan te geven dat een artikel beoordeeld is en wat voor een label erop moet.
Hoe gaan mijn productiemedewerkers dit anders uit elkaar houden.

Dus kan er in lOAR een indicator komen die de volgende modi kent?
omschrijving bv: "GHS label"
"-" = nvt (default)
"J" = JA
"N" = Nee

Dan kan ik die dadelijk bv in de Productieorder header terug laten komen.



mvg

Marco

Kun je dat niet met je Etiket-Layout regelen?

Huidige voorzie je van de tekst "WMS" en voor de nieuwe kreëer je een "GHS/CLP" etiket.  :smile:

Ik zit te denken vanuit de andere kant:
Hoe weet een productieman of een werkvoorbereider welk label hij moet gaan printen en plakken?
WMS of GHS
Er is nu geen eenduidige aansturing van de mensen.

of heb jij een beter idee?

Door die Etiket Layout Identifikatie (of omschrijving) op je P.O. weer te geven ?

ik zat eraan te denken om in de header een veld te maken:


GHS Label: nvt/JA/NEE


Bij Ja moeten ze het nieuwe GHS label printen
Bij Nee het oude label
en bij nvt vragen (want dan heb ik mijn werk dus nog niet goed gedaan en de indeling aangegeven.

Wouter is dit accoord?
en voor mijn planning: Wanneer denk je dat ik een upgrade moet gaan draaien ?

Wouter is er niet goed van geworden. :yes: En morgen vrij.

was niet voor niets al een jaar geleden begonnen met jullie wakker te schudden....

als hij er echt ziek van geworden is: beterschap...

Mocht je op "de" upgrade zitten te wachten, die is op zich klaar hoor. Misschien had ik dat meteen moeten melden.
Het is, meen ik, nog niet 100% klaar, maar wat klaar is kan je krijgen. Als je liever nog even wacht, is dat denk ik beter.

Status update conform jouw eerdere topic:


Zoals eerder gemeld, deze is klaar. Zie ook http://ha1.heartprofit.nl/profit/index.php?topic=23087.0


Derhalve n.v.t.


- Huidige P- Zinnen worden tijdens de Upgrade vertaald naar T-Zinnen; zie http://ha1.heartprofit.nl/profit/index.php?topic=23076.0
- Registratie P- H- en EU-Zinnen mogelijk; zie http://ha1.heartprofit.nl/profit/index.php?topic=23082.0 en http://ha1.heartprofit.nl/profit/index.php?topic=23085.0
- CLP/DPD indikator is hier niet van toepassing; de gebruiker bepaalt middels Standaard Elementen of Layoutvariabelen zelf welke Zinnen ze wenst te gebruiken.
- Lengte Identifikatie R&S Zin is niet gewijzigd, de voorbeeld P-Zin kan worden opgenomen als P371/380/375 of P371+380+375 en past dan binnen het huidig aantal posities.




Klaar (ook al eerder gemeld).


Layoutvariabelen & Standaard Elementen zijn hierop aangepast.
Waar je eerst Layoutvariabelen had voor bijv. R- S- en T- Zinnen, heb je nu ook variabelen voor H- P- en EU- Zinnen erbij.
Afhankelijk van je Etiketlayout kun je zelf bepalen welke je erop op wilt nemen (desnoods beide, ook al mag dat formeel misschien niet).



Nee. Geen nieuwe Raadpleegfunkties of sorteringen erbij gekomen. De R&S Zinnen zijn sowieso al gesorteerd op de 1e letter, dus de R- S- T- P- H- E- Zinnen herken je zo ook wel.



Je P.O. Layout moet nog worden aangepast; graag een voorbeeld sturen van je layout + wat je waar aangepast wenst te hebben.


N.v.t., sinds je zélf refereert aan een R- S- T- P- H- E- variabele. Jouw opmerking was bedoeld voor de situatie dat je twee P-Zinnen kon definieren, één setje voor WMS en één setje voor DPD, en dan zou de indikator van het etiket of i.d. moeten afdwingen met welke P-Zin e.e.a. gevuld moest worden. Is nu dus anders opgezet.

Resumer: volgens mij zijn alle aanpassingen nu klaar (op je P.O. layout na).

Dat is een herhaling van wat je al geschreven had... Wat is er mis met mijn idee ?
Feitelijk ga je op jouw manier een nieuw veld opnemen wat verder helemaal niets doet in Profit, behalve afdrukken op jouw P.O. Layout...

Dus, mijn idee:
Bij je Artikel (of je Artikel-/Verschijning) vul je een Etiket Layout "GHS" of "WMS" in (of een andere Etiket layout of je laat het veld leeg). Dit betreft een veld wat je sowieso moet invullen, immers je GHS layout zal P- H- en EU- Zinnen bevatten, en je WMS layout bevat R- S- en T- Zinnen.

Dus, laat je P.O. layout zodanig aanpassen dat deze weergeeft:

Etiket-Layout : GHS  / WMS / ...

Wat is daar mis aan ?

Op jouw manier ga je iets redundants kreëren, en de ingevulde waarde doet verder ook nog eens niets. Dus, je zou GHS label op Ja kunnen zetten, maar vervolgens komt er inhoudelijk gewoon de tekst van een WMS label op...

Wat daar mis aan is, is dat op debiteur niveau ook een veld etiket layout bestaat en deze overstijgt mijn artikel instelling (is trouwens in 99% ook de gewenste situatie)
Ik heb dus een artikel afhankelijke indicator nodig om aan te geven dat het hier een GHS of WMS artikel is.

En die moet juist niet debiteur afhankelijk zijn.

En ik wil dit wel op de PO header kwijt.

PS Dat word in de header 2e kolom net onder Totaal recept in liters....
Daar heb ik nog een "vakje" vrij, maar daar doe ik een aparte aanvraag voor, want er zijn nog een paar items die aangepast moeten worden

de factuur is sneller dan de upgrade..... :wink:

Tsja... het versturen van de faktuur initiëren wij,
het aanvragen van een Upgrade jij.  :wink:

Etiketlayout op Debiteurniveau... die is nieuw voor mij.

Zolang je niet alle Artikelen hebt ingericht op de manier die door de Debiteur wordt afgedwongen, gaat dat toch niet werken...

Ik bedoel, met de rubriek wil je op Artikelniveau aangeven of het een GHS of een WMS Artikel is (klopt dat wel, en bedoel je niet om aan te kunnen geven "of je dit Artikel al hebt ingericht voor GHS J/N"). Met als uitgangspunt dat het wél is zoals je schrijft, en je én GHS én WMS artikelen hebt, dan kun je nóóit op Debiteurniveau één Etiketlayout opgeven, waar de Etiketlayout van GHS andere variabelen aanstuurt dan die van WMS.

Kun je e.e.a. nog eens duidelijk toelichten (misschien even makkelijker per telefoon). :(

Resulaat van het tel. gesprek:

Het Artikel dwingt af of een GHS label verplicht is (enkelvoudige grondstoffen, of speciaal in de wet genoemde artikelen), of het nóg niet verplicht is (mengsels) danwel het helemaal niet van toepassing is (water).

Normaliter geldt dat je via de Artikelgegevens prima kunt regelen welk produkt een GHS label danwel een WMS label moet hebben, simpelweg door bij dat Artikel een Etiketlayout in te vullen die GHS/WMS impliceert.

Een Etiketlayout op Debiteurniveau kan worden opgenomen omdat dié Debiteur een specifiek etiket wenst; andere indeling, zijn naam/logo erop etc. De Etiketlayout die je daar opneemt bevat óf GHS óf WMS variabelen (beide mag immers niet, ook al kan dat technisch wel). Één instelling, enkel op Debiteurniveau, kan derhalve nooit werken. Maar... het blijkt dat op Debiteur-/Artikelniveau het Etiketlayout v/d Debiteur weer overruled kan worden, en dáármee was mdekraa van plan te regelen dat standaard de produkten voor die debiteur gelabelled zouden worden als "Debiteur-X-WMS", maar speciale produkten als "Debiteur-X-GHS".

De rubriek op Artikelniveau is daarmee wél nodig, maar nu puur bedoeld als visuele kontrole: als het Artikel afdwingt dat er een nieuw etiket op moet, mag het niet zo zijn dat er een Etiketlayout wordt gebaseerd op de oude layout. Dit zou impliceren dat er een Debiteur-/Artikel kombinatie niet juist ingericht is. De betreffende rubriek zal alsnog worden opgenomen bij het Artikel.

Rubriekje is opgenomen bij het Artikel, maar je P.O. layout is nog even niet aangepast.


Dat "vakje" is daar niet vrij, want daar wordt (indien aanwezig) reeds het Klant-Artikelnummer afgedrukt.

Doe maar onder klantartikel dan

Aangepast, maar daarmee w.s. nog niet klaar, immers :


Wellicht weergave H- & P- Zinnen bijvoorbeeld.

Voorstel:

Graag Productieorder aanpassen conform onderstaande:

 

(1)

Onder artikel staat nu een indicator mbt WMS/GHS label.
Dat word in de header 2e kolom net onder klantartikelnummer....

Daar heb ik nog een "vakje" vrij.

Presentatie:

            Labelvoorschrift: WMS/GHS/n.v.t.

 

(2)

Op regelniveau van de grondstoffen staat nu het vlampunt gevolgd door de R en S zinnen, kommagescheiden in volgorde.

Hier graag een regel onder met de nummers van de relevante H, EUH en P zinnen (in die volgorde)

 

(3)

Na de receptuur staat er een blok “Veiligheid”

Tussen WMS labels en UN nummer graag een blok invoegen met de GHS klassificatie zoals deze onder J1 en J2 van het artikel is vastgelegd.

Dus:

GHS labels           :   GHS01, GHS02 enz
H en EUH zinnen :   H300, H400 enz
P-zinnen               :   P100, P200 enz.

Qua uiterlijk gelijk aan huidige WMS blokjes.....

(1) Aangepast.

(2) Aangepast; In het 1e blok worden ook de T- Zinnen afgedrukt (omdat dat voorheen ook gebeurde); wil je expliciet alleen R&S Zinnen, dan even expliciet aangeven (immers, dat werkt dat deel anders dan voorheen). Nu neem ik aan dat je e.e.a. "vergeten" bent danwel de T-Zinnen (= oude P-Zinnen) niet gebruikt.

(3) Aangepast; doch v.w.b. de informatie bepaald wordt o.b.v. de Artikelgegevens. Er blijken nl. 2 methodes in de P.O. Layout gehanteerd te worden:

a. eerst een MSDS genereren o.b.v. de Receptuur + Eigenschappen, en dáár de gegevens uit te lezen

b. kijken welke gegevens er aan het geproduceerde artikel zijn gekoppeld

Als a. niets oplevert, treedt b. in werking.

Van a. weet ik zo 1,2,3 niet hoe ik dat moet inrichten + testen, maar, even een voorbeeld gedraaid op jullie systeem (ART1011740), en daarbij treedt a. helemaal niet in werking en wordt sowieso b. toegepast. Vooralsnog heb ik dus alleen b. aangepast. Als ART1011740 representatief is voor al je artikelen, dan zou dit moeten werken (maar, het genereren van een MSDS o.b.v. de Receptuur zit er vast niet voor niets in). Even in de gaten houden dus.

En nu?

Upgrade voor je klaarzetten ??

Met dank Wouter, zal even thuis checken wanneer ik een avond mag werken  :wink:


(1) thx
(2) OK
(3) Ik was alleen bewust van methode (b), waarschijnlijk is (a) erin gezet vanuit genereren proper shipping of zo? kan geen kwaad, wij gebruiken alleen (b) operationeel.

Ok, alles lijkt te werken, wanneer kan ik de aanpassing van mijn PO verwachten?

De (1), (2) en (3) refereren aan je aanpassingen op je PO Layout.
Ik heb dus al aangegeven dat dit klaar is... (en dus zou je dit met de Upgrade moeten hebben ontvangen).

Ik zie dat het niet met een Upgrade is overgezonden. Zal eens uitzoeken waarom niet, en dit alsnog nazenden.

Nou... wie normaliter de aanpassingen verricht + overstuurt inzake jullie klantspecifieke funkties weet ik niet, maar de "Alternatieve Funkties" van jullie zijn bij ons zodanig verkeerd ingericht, dat deze nooit met een Upgrade kunnen zijn overgezonden  :(

Ik heb e.e.a. voor een volgende keer aangepast. Heb de aanpassing van de P.O. nu handmatig overgezonden. Probeer het nog eens. :smile:

hij doet het nu
met dank

wouter?
Ik krijg de Id "P371+380+375" niet geplaatst in het veld bij de functie LORSTV
Ik kom maar tot "P123+P456+P1"

Één van ons kan niet tellen denk ik

Tsja... ervanuitgaande dat ik wel kan tellen, moet jij dat wel zijn  ;D

Maar, misschien ben je gewoon in de war  :wink:

Zie notabene wat je zelf quote:


dan je passende voorbeeld:


en dan hetgeen wat niet past:


P123+P456+P1
P371+380+375

Past precies  :smile:

Ok
we laten de tussen letters dus weg, geen probleem