E-communicatie met de Rijksuniversiteit Groningen

facilitair bedrijf

facilitaire informatisering

E-communicatie met de Rijksuniversiteit Groningen Ondersteunde manieren van elektronische opdrachtflow Versie 1.1 (concept)

2 december 2013

E-communicatie met de Rijksuniversiteit Groningen › 2

Inhoudsopgave 1

Introductie

3

2 2.1 2.2 2.3

Uitwerking B2B scenario B2@ scenario Web2Client scenario

4 4 4 4

3 3.1

Sjablonen en workflow B2B 3.1.1 B2B XSD’s 3.1.2 SFTP-server 3.1.3 B2B workflow B2@ 3.2.1 B2@ sjablonen 3.2.2 B2@ workflow Web2Client 3.3.1 Web2Client layout 3.3.2 Web2Client workflow

3.2 3.3

5 5 5 5 6 7 7 8 9 9 10


1

Introductie

De Rijksuniversiteit Groningen (RUG) streeft naar een zo efficiënt en betrouwbaar mogelijke wijze van communicatie met haar leveranciers betreffende opdrachten en meldingen. In de zienswijze van de RUG wordt deze wens het best ingevuld door zogenaamde ‘Business to Business’ (B2B) koppelingen te realiseren, waarbij het workflowsysteem van de leverancier met het workflowsysteem van de RUG wordt gekoppeld. Het is voor de RUG essentieel om haar logistieke processen goed in de grip te hebben. Intern ondersteunen wij dit door gebruik te maken van workflowimplementaties in ons servicemanagementsysteem. Vanuit dit systeem publiceren wij op een logisch geborgde en beveiligde manier onze opdrachten en meldingen voor leveranciers. Wij verwachten van leveranciers op dezelfde manier terugkoppeling over de status van voortgang en eventuele nodige details betreffende de opdracht of melding. Waar een leverancier niet in staat is om haar systeem te koppelen ofwel niet over een systeem beschikt biedt de RUG haar leveranciers een front-end aan, dan wel hosted, dan wel lokaal bij de leverancier. Wij noemen deze communicatiemethode de B2@-koppeling. De RUG publiceert haar opdrachten en meldingen op dezelfde manier als bij een B2B-koppeling, maar de leverancier ontvangt deze per email als formulier. Naast de bovenstaande mogelijkheden van koppelen van systemen bieden we ook de mogelijkheid in te loggen in een gedeelte van ons servicemanagementsysteem. Dit bied een aantal voordelen, waaronder dat je altijd in dezelfde dataset werkt en dat we meer aanvullende informatie kunnen ontsluiten. Wij noemen dit de Web2Client.


2

Uitwerking

2.1 B2B scenario De RUG wil haar communicatie met leveranciers zo veilig, efficiënt en bedrijfszeker uitvoeren. Intern gebruiken wij ons ondersteunende managementsysteem waarmee wij onze interne workflow middels automatisering ondersteunen. Hiermee hebben wij grip op procesdoorloop, opdrachten en de daaropvolgende statusovergangen zijn vastgelegd en informatie is snel en eenduidig beschikbaar. Van inschrijvers eist de RUG een zelfde inzicht in de procesdoorloop. Om deze procesdoorloop goed te beheersen heeft de RUG gekozen voor communicatie met leveranciers via een sftp-server die de RUG zelf beheert. De RUG publiceert op deze server opdrachten in xml-formaat voor de leverancier. Deze opdrachten zijn geschreven op basis van een door de RUG gedefinieerd sjabloon. Van de leverancier wordt verwacht dat terugkoppeling geschied volgens eveneens door de RUG gedefinieerde sjablonen. De leverancier pakt de opdracht op van de server, importeert deze in haar eigen systeem en zet het originele bericht in een ‘verwerkt’-map op dezelfde locatie. De leverancier geeft op afgesproken momenten terugkoppeling aan de RUG. Deze terugkoppeling zet de leverancier in een daartoe aangewezen map op dezelfde server. De RUG importeert dit bericht in haar systeem en zet het originele bericht in een ‘verwerkt’-map op dezelfde locatie. 2.2 B2@ scenario De RUG realiseert zich dat niet alle inschrijvers die willen deelnemen aan een aanbesteding over een (koppelbaar) systeem beschikken en daarmee geen B2B koppeling kunnen realiseren. Om het voor deze partijen toch mogelijk te maken om op een aanbesteding in te schrijven stelt de RUG een alternatieve ‘losse’ koppelingsmogelijkheid ter beschikking aan leveranciers. Wij noemen dit het B2@-scenario, aangezien de leverancier opdrachten per email ontvangt en op dezelfde wijze terugkoppeling geeft. De RUG maakt gebruik van een derde partij om opdrachten aan de leverancier te versturen. De RUG publiceert haar berichten op dezelfde server als in het B2B-scenario en verwacht ook terugkoppeling op eenzelfde wijze. Met een derde partij stellen wij een pdForms-oplossing ter beschikking aan leveranciers, waarbij de derde partij de op de server staande berichten omzet naar pdf-data wat bij de leverancier in een sjabloon getoond wordt. Middels dit sjabloon geeft de leverancier terugkoppeling. 2.3 Web2Client scenario Als extra alternatief voor het B2B scenario heeft de RUG een webportal voor leveranciers ingericht, hierna Web2Client genoemd. Hiermee kan worden ingelogd op een beperkt deel van ons servicemanagementsysteem. Het voordeel van deze oplossing is dat zowel opdrachtgever als -nemer in dezelfde dataset werkt en daarmee altijd over dezelfde informatie beschikt. Tevens kan er via deze tool extra informatie worden gedeeld en kunnen er bestanden worden uitgewisseld. Daarnaast is er bij dit scenario standaard al rekening gehouden met een mogelijk offerte traject. Bij dit scenario krijgt de leverancier een mail met daarin een aantal basisgegevens over de opdracht en een link naar het de Web2Client. Als er op de link wordt geklikt zal de Web2Client worden geopend in een webbrowser en kan de leverancier inloggen. Hier staan een aantal statusafhankelijke “werkbakjes” klaar met daarin de verschillende opdrachten. Afhankelijk van de status waarin de order zich bevind zijn er verschillende acties die uitgevoerd kunnen worden.


3

Sjablonen en workflow

3.1

B2B 3.1.1 B2B XSD’s Voor dit scenario zijn 3 XSD’s van toepassing: 1 Order.xsd In dit bestand is gedefinieerd hoe de opbouw en inhoud van het orderbericht vanuit de RUG naar de leverancier eruit ziet. 2 Orderconfirmation.xsd In dit bestand is gedefinieerd hoe de opbouw en inhoud van de bevestiging van ontvangst en verwerking van het orderbericht van de leverancier naar de RUG er uit moet zien. 3 Delivery.xsd In dit bestand is gedefinieerd hoe de opbouw en inhoud van de verzendbevestiging van de leverancier naar de RUG er uit moet zien. Als losse bestanden zijn bovenstaande XSD’s toegevoegd. Ook is er van elke XSD een voorbeeld XML toegevoegd. Daar waar er gebruik wordt gemaakt van codes (zoals codes voor BTW-tarieven en dimensies) zijn deze zo mogelijk gebaseerd op schema’s van de UN/CEFACT. Wij maken hierbij gebruik van de laatste versie zoals die op de volgende website gepubliceerd is: http://www.unece.org/cefact/recommendations/add2a.htm 3.1.2 SFTP-server Bij dit scenario wordt er bij de communicatie gebruik gemaakt van een SFTP-server die in beheer is bij de RUG. Om hierop aan te sluiten moeten de volgende gegevens worden aangeleverd: - het IP-adres of de IP-adressen waarvandaan verbinding met de SFTP- server moet worden gemaakt; - de bij de IP-adressen behorende publickeys. Hieronder volgen gegevens m.b.t. de SFTP-server Servernaam: files.service.rug.nl Loginnaam: is een afgeleide van de naam van de betreffende leverancier Directorystructuur (waarbij **** staat voor de leverancier): De productie-homedirectory is ****PRD met de volgende directorystructuur: ****PRD\Outbox\Processed ****PRD\Inbox\Processed De test-homedirectory is ****TST met de volgende directorystructuur: ****TST\Outbox\Processed ****TST\Inbox\Processed


Phase

3.1.3 B2B workflow Op het volgende schema is het proces van versturen en ontvangen van de XML-berichten uitgewerkt.


3.2

B2@ 3.2.1 B2@ sjablonen Bij dit scenario ontvangt de leverancier voorgedefinieerde PDF-invulformulieren die te openen zijn met o.a. de gratis Adobe PDF-reader. Met behulp van deze formulieren kan de leverancier opdrachten van de RUG lezen en feedback geven over de status van uitvoering. Deze formulieren worden vanaf een centrale voorziening beschikbaar gesteld en geopend door een pdf-databestand als attachment van een email te openen.


3.2.2 B2@ workflow In het volgende schema is het proces van versturen en ontvangen van de XML- en PDFberichten uitgewerkt.


3.3

Web2Client 3.3.1 Web2Client layout In dit scenario ontvangt de leverancier een mail met daarin een omschrijving van de opdracht en een link naar de Web2Client. Hieronder een screenshot van de Web2Client.


3.3.2 Web2Client workflow In het volgende schema is het proces van versturen en ontvangen van de opdrachten uitgewerkt.


E-communicatie met de Rijksuniversiteit Groningen

Recommend Documents