FAQ

Algemeen

  • Kan ik voor verschillende rollen (bijv. shipper en leverancier) één EAN-code gebruiken?

    Ja, dat is mogelijk. Als de shipper- en leveranciersrol gecombineerd worden, en er dus van één EAN-code gebruik gemaakt wordt, krijgt deze partij (van GtS) alle berichten zoals die gelden voor een leverancier en alle berichten zoals die gelden voor een shipper. De informatie in de berichten voor shipper en leverancier kunnen namelijk verschillen. Voorbeeld: de TINFO is gelijk maar de LALL verschilt. N.B. De backofficesystemen moeten hiermee om kunnen gaan. Het versturen aan andere partijen wordt dan ook voor alle berichten, van zowel shipper als leverancier, met één beveiligingssleutel ge-encrypt en ge-signed. De communicatie vindt plaats via één AS2 connector en IP-adres. Er wordt per EAN-code één beveiligingscertificaat afgegeven. M.a.w. als de shipperrol en de leveranciersrol elk een eigen EAN-code hebben dan worden berichten per rol verstuurd en versleuteld met het beveiligingscertificaat dat hoort bij de EAN-code. Dit houdt in dat de AS2- applicatie hiermee om moet kunnen gaan, door b.v. gebruik te maken van aparte ip-adressen of aparte url´s (webpagina´s) om inkomende berichten te kunnen ontvangen. Het verdient de voorkeur om voor elke rol een aparte EAN-code te gebruiken.

  • Kan ik oude e-mail berichten gebruiken na 1-1-2004?

    Nee, de nieuwe berichten (zoals gedefinieerd in de MIG) zijn de enige berichten die gebruikt kunnen worden. De oude e-mail berichten bevatten niet alle benodigde informatie en alle overige partijen hebben tevens de nieuwe MIG-berichten geïmplementeerd.

  • Wat is een werkdag?

    De volgende dagen zijn geen werkdagen:

    Weekeinde:
    - Zaterdag
    - Zondag

    Nationale feestdagen:
    - Koninginnedag (30 april)
    - Bevrijdingsdag (5 mei)

    Algemeen erkende en christelijke feestdagen:
    - Nieuwjaarsdag (1 januari)
    - Goede vrijdag
    - Pasen
    - Hemelvaartsdag + vrijdag na Hemelvaartsdag
    - Pinksteren
    - Kerstmis (25, 26 december)

VPN AS2

  • Wij hebben als partij meerdere rollen. Mijn AS2 software is echter niet in staat om afhankelijk van de rol (en dus EAN-code) waarvoor een bericht wordt verstuurd te gebruiken?

    Doel
    Dit document is bedoeld om alle betrokken partijen te informeren omtrent een zaak die speelt rond AS2 communicatie. Dit document beschrijft geen directe oplossing voor een probleem, wel een workaround, dat wordt beschreven, maar is bedoeld om onduidelijkheid weg te nemen.

    Berichtenuitwisseling
    Iedere partij die berichten uitwisselt op het VPN heeft een eigen unieke EAN-code. Als een partij meerdere rollen vervult, is het aanbevolen (maar niet afgedwongen) dat ook voor iedere rol een eigen EAN-code beschikbaar is. Hiermee is iedere zender en ontvanger van berichten op het VPN uniek. Op basis van de EAN-codes worden vervolgens de certificaten uitgegeven, waardoor een koppeling ontstaat tussen EAN-code en digitaal certificaat. Door deze ‘koppeling’ is het dus mogelijk om de identiteit van een zender niet alleen vast te stellen op basis van de EAN-code, maar ook te verifiëren op basis van het gebruikte certificaat. Door deze ‘koppeling’ is het mogelijk om
    “EAN-code <=> certificaat” combinaties te detecteren en (afhankelijk van de gebruikte AS2 software) de berichten te weigeren of te accepteren.

    Situatie
    Op dit moment doet zich de situatie voor dat er AS2 software wordt gebruikt door partijen die het berichtenverkeer voor meerdere rollen afhandelen (Shipper, RNB, Leverancier rol of meerdere rollen van een soort) op één IP adres (een server). Sommige AS2 software is echter (nog) niet in staat om afhankelijk van de rol (en dus EAN-code), waarvoor een bericht wordt verstuurd, het bijbehorende digitale certificaat te gebruiken. Daarnaast doet zich het probleem voor dat het alleen mogelijk is om 1 URL te configureren waar de berichten naar toe gestuurd worden.

    In de praktijk komt het er op neer dat deze AS2 software alle berichten voor alle rollen verstuurt onder de identiteit (dus het certificaat) van een van de rollen en dat alle berichten naar één mogelijke URL van de ontvangende partij worden gestuurd.

    Afhankelijk van de AS2 software die aan de ontvangende zijde wordt gebruikt, levert bovenstaande een probleem op als een aparte URL per rol (bijv. het gebruik van een EAN code in de URL) is gespecificeerd voor het ontvangen van de berichten.
    Per URL is dan ook alleen het bijbehorende certificaat beschikbaar voor het controleren van de identiteit van de verzender.

    Gevolgen
    Voor zover nu bekend is doet het bovenstaande probleem zich voor bij partijen die XIB/Cyclone commerce AS2 software gebruiken. Naar nu bekend treden er in de communicatie met partijen die HP CATS gebruiken problemen op.

    Workaround
    De mogelijke work around is dat de betrokken partijen onderling afspreken dat de communicatie richting HP CATS via 1 URL en digitaal certificaat wordt afgewikkeld (één van de rollen). Dit betekent dus ook dat de berichten komend van een XIB/Cyclone commerce systeem onder 1 identiteit worden verstuurd en dus, voor alle berichten naar een (HP CATS) partij, het certificaat zal gebruiken dat bij die ene, afgesproken, EAN-code hoort.

    Partijen waarbij dit speelt zullen dit dus onderling moeten afstemmen. Houd dit in het achterhoofd: De oplossing van dit probleem wordt dus gelegd bij de partij die zelf geen probleem heeft.

    Dit is een tijdelijke work around, partijen die gebruik maken van software die problemen geeft (XIB/Cyclone commerce) zullen met hun softwareleverancier in contact moeten treden en erop moeten aandringen om de software aan te passen.
     

  • Per 1 juli a.s. ben ik van plan als leverancier toe te treden tot de markt. Moet ik dan ook gebruikmaken van het VPN voor het gasallocatie-berichtenverkeer?

    Binnen PVE-verband is afgesproken welke partijen gebruik gaan maken van het VPN en welke informatie via dit VPN wordt verstuurd. Deze partijen zijn, naast GtS zelf, de RNB´s, shippers en leveranciers. In de presentaties van onze informatie dagen vindt u nadere details over de informatie die via dit VPN wordt uitgewisseld.

  • Zijn er specificaties voor de inrichting van AS2?

    Ja

    • Encryptie: 3DES
    • Signing: SHA1
    • Compressie: on
    • MDN: Synchronous signed
    • AS2 to/from: EAN code als identifier
    • Geen servercertificaat (dus geen HTTP´s)

  • Krijgt een partij voor haar verschillende rollen verschillende sleutels/certificaten?

    Ja. Deze partij gebruikt dus verschillende ip-adressen (voor de AS2-connecties) per rol.

  • Welke bandbreedte heeft Gastransport Services bijvoorbeeld met het BT-netwerk?

    Een 2Mb-verbinding.

  • Met welke hoeveelheid data moeten wij naar jullie inschatting rekening houden?

    Dit is een inschatting die zelf gemaakt moet worden. Hieronder een rekenvoorbeeld:
    Schatting van de netwerkverbinding
    Als we nu de tijd willen schatten die nodig is om de berichten in een ´worst case´-scenario te verzenden, kunnen we de volgende formule gebruiken: T
    Tijd = Max. aantal berichten * Max. bericht grootte (in byte) * 8 0.
    9 * Bandbreedte (bits/sec) * Feff * Fcomp
    Waarin: Max. aantal berichten = Max. aantal meetpunten = 400 (GtS)
    Grootte van het bericht
    De grootte van het bericht wordt bepaald door het gemiddelde aantal leveranciers en het gemiddelde aantal leveranciers per categorie. In de MIG´s (Message Implementation Guidelines for PVE messages (draft- v.4)) wordt voorgeschreven dat per meetpunt in één bericht alle gegevens van elke leverancier/afnemer-paar gegeven wordt. Voor het ´worst case´-scenario nemen we het grootste bericht, dus het LALL-bericht. Op basis van bovenstaande wordt de grootte ca. 1500K. Overige waarden Voor het verzenden van de berichten wordt AS2 gebruikt. Standaard in AS2 staat: compressie. De compressiefactor, Fcomp, schatten we, zoals waargenomen in testen, op 25. Het gebruikte protocol voor berichtenverkeer veroorzaakt enige overhead. De efficiëntiefactor, Feff, schatten we op 0.7. De schatting is dat 90% van de bandbreedte wordt gebruikt voor deze file-transfers, er kan namelijk tegelijkertijd ook een (antwoord)bericht van de andere kant komen, de factor is 0.9. 8: van bytes naar bits. Een rekenvoorbeeld voor GtS is dan:
    Tijd = 400 * 1500000 * 8 = 171 sec.
    0.9 * 2000000 * 0.7 * 25.
    We gaan uit van een 2Mbit/sec-verbinding voor GTS.

  • Hoe zit de infrastructuur van Gas Transport Services er voor gasallocatie verder uit?

    De infrastructuur bestaat uit een Biztalk met Covast EDI accelerator en AS2 adaptor; daarachter zit een berichten-handler die de confirmatieberichten terugstuurt. Dáárachter zit weer een soort business warehouse waarin alle relaties tussen allocaties, marktpartijen enz. zijn opgeslagen.

  • Welke specificaties hebben de verschillende servercomponenten voor het AS2 EDI-berichten verkeer?

    Dit is geheel afhankelijk van de gekozen oplossing, er moet dus een sizing worden gedaan die is gebaseerd op de huidige kennis. Tijdens het proefdraaien moet het systeem nog kunnen worden aangepast, hetzij kleiner (meestal niet) of groter worden gemaakt. Het systeem moet gemakkelijk te sizen zijn. Er zijn oplossingen gebaseerd op één server, maar er zijn ook load balancing-scenario´s denkbaar. Ook moet de vraag worden beantwoord op welk systeem bepaalde processen plaatsvinden. Gastransport Services heeft de functionaliteit opgesplitst in messaging (vertaling en communicatie), controleren (inhoudelijk op bericht en confirmeren) en verwerken/genereren (alle berekeningen doen en de juiste berichtinhoud genereren).

  • Hoe richt ik het netwerk infrastructureel in wat betreft NAT, IP-adressen, Firewall etc.?

  • Als ik nog geen VPN-aansluiting heb, kan ik dan toch beginnen met KEMA-testen?

    De procedure is zodanig dat er eerst een VPN-aansluiting wordt aangevraagd en aangelegd. Na de contractondertekening met BT Nederland (let op de doorlooptijd) en het plaatsen van de order wordt binnen 40 werkdagen een VPN-verbinding opgeleverd. Er zijn enkele partijen waarbij de aanvraag van deze verbinding vertraging heeft opgeleverd (niet te wijten aan BT Nederland), maar die wel de systemen gereed hebben. Om deze partijen tegemoet te komen, is onderzocht of het mogelijk is om op een andere wijze toegang te krijgen tot de Kema-testfaciliteit. Na diverse mogelijkheden te hebben afgewogen*, blijkt een directe ISDN-verbinding met Kema de snelste oplossing die de integriteit van het VPN niet aantast. De verwachting is dat er vanaf 1 november een verbinding met Kema gemaakt kan worden. De verkrijgbaarheid van een Cisco ISDN-router is nog een onzekere factor, ook moet er nog een ISDN-lijn worden aangelegd. Indien een partij in aanmerking wil komen voor deze oplossing dient deze zich aan te melden bij de NOVA-postbus, waarna de partij wordt ingepland. Uitgangspunt is dat de interne testen (goed) doorlopen zijn, hiervoor kan het spreadsheet ook worden gebruikt (aanvragen via nova@gasunie.nl). De precieze invulling en de procedures moeten nog worden vastgesteld. De partij die wil testen, moet ook over een Cisco-router beschikken om incompatibiliteit op hardwareniveau te vermijden. *) De volgende mogelijkheden zijn afgewogen:
    - Via internet
    Kema heeft geen route vanaf internet naar de testfaciliteit
    IP-nummeringprobleem
    Grote inspanning om beveiliging te waarborgen; KEMA is nu niet verbonden met het internet
    Er wordt geen gebruik gemaakt van SSL
    - Via ISDN naar GTS en dan naar VPN
    Doorlooptijd ca. 7 weken i.v.m. bestellen router
    NAT-configuratie is zodanig dat GtS niet bereikbaar is tijdens testen van derde partij. Tevens is schaduwdraaien met GtS is hierdoor niet tegelijk mogelijk met KEMA-testen
    - Opsturen van testbestanden via e-mail
    Geen realistische situatie/test
    Testen gebeurt door berichtenuitwisseling en niet met bestanden. (Een deel van de testen kan men zelf uitvoeren m.b.v. het spreadsheet)
    - Fysiek naar KEMA toe gaan
    Dit is alleen mogelijk indien het een klein systeem betreft (PC oplossing)

LET/CET

  • Wat zijn de consequenties voor de datum-definitie van EDIG@S (= UTC 0) m.b.t. het feit dat GTS heeft besloten om per 1 januari 2004 LET (local european time) te hanteren?

    Functioneel
    Functioneel (zie eindrapport PVE-werkgroep 12) gelden de berichten MINFO, LALL, BALL, CINFO voor een gasmaand in LET en het TINFO-bericht voor een gasdag in LET. Dit betekent dat het eerste uur van een dergelijk bericht loopt van 06:00 uur tot 07:00 uur LET en het laatste uur van 05:00 uur tot 06:00 uur LET.


    Technisch
    Zoals aangegeven in de Edigas MIG introduction, paragraaf 4.2.1 Time identification, wordt ten zeerste aanbevolen om in de berichten als tijdbasis UTC te gebruiken. Deze aanbeveling volgen we op en we gebruiken dus geen LET in de Edigas-berichten. Gevolg is o.a. dat we niet worden geconfronteerd met dubbbele berichten bij de overgang van de zomer naar de winter of van de winter naar de zomer (als aangegeven in paragraaf 4.2.2).
    Voorbeeld
    Er wordt een LALL-bericht verstuurd voor de maand maart 2004. Eind maart zal de winter/zomer overgang plaatsvinden.

     

      1-ste uur van bericht  laatste uur van bericht
    Functioneel 06:00 - 07:00 LET 05:00 - 06:00 LET
    Technisch 05:00 - 06:00 UTC 03:00 - 04:00 UTC

     

  • Wat is de reden van GTS om LET te hanteren?

    Dit is conform afspraken tussen gasbedrijven in Europees verband.

  • Wij hebben geconstateerd dat bij de overgang van winter- naar zomertijd (en vice versa) de kans bestaat dat er meerdere berichten met dezelfde datum ontvangen worden?

    Dit is niet het geval, zie bovenstaand.

Edigas allocatie-spreadsheet

  • Waar kunnen wij de spreadsheet vinden?

    Deze kunt u aanvragen via nova@gasunie.nl.

  • Moeten wij de spreadsheet ook bij KEMA testen?

    Ja, voor de spreadsheet in combinatie met een HP Cats-oplossing geldt een verkort testscenario.

  • Onder Windows 98 geeft de spreadsheet enkele problemen. Kan dit aan Windows liggen?

    De spreadsheet is door Gastransport Services getest onder Windows 2000 en Microsoft Office 2000. Uiteraard staat het u vrij om de spreadsheet onder een andere dan genoemde configuratie te gebruiken, maar dit is voor eigen risico.

    Voor een compleet overzicht van alle Edigas MIG´s verwijzen wij u naar de officiële Edigas website: www.edigas.org/

KEMA-testen

  • Wat is de afhandeling van Interchange Reference Number (IRN) en Message Reference Number (MRN)?

    Het IRN moet een uniek nummer zijn.

    Het MRN mag in verschillende berichten, in combinatie met een andere IRN, meerdere keren voorkomen.

    Bij KEMA worden deze referentienummers in respectievelijk Tx01280 (IRN) en Tx02030 (MRN) getest. Voor deze testen betekent dat:

    • Tx01280 ongewijzigd blijft
    • Tx02030 is aangepast zodat het accepteren van eenzelfde MRN wordt toegestaan.
       

  • Welke stappen moet ik ondernemen om te kunnen beginnen met testen?

    Om te kunnen beginnen met testen moet u contact opnemen met KEMA. KEMA zal u een digitaal testcertificaat verstrekken waarmee u de testen die nodig zijn voor het behalen van de Attestation of Conformity kunt doorlopen.

  • Als ik nog geen VPN-aansluiting heb, kan ik dan toch beginnen met KEMA-testen?

    De procedure is zodanig dat er eerst een VPN-aansluiting wordt aangevraagd en aangelegd. Na de contractondertekening met BT Nederland (let op de doorlooptijd) en het plaatsen van de order wordt binnen 30 werkdagen een VPN-verbinding opgeleverd.

  • Wij ontvangen berichten waar wij op dit moment niets mee doen (bijvoorbeeld TINFO-bericht voor shipper). Moeten wij deze berichten dan toch meenemen in de KEMA-test?

    Het is per rol bepaald welke berichten worden verstuurd en dus ook worden getest. Als een partij ervoor kiest om een bepaald bericht niet te gebruiken, zal dit bericht dus toch getest moeten worden als het bij de rol van die partij hoort.

MINFO-bericht

  • Levert Gas Transport Services in het MINFO-bericht de meetgegevens op GOS- of op PseudoGOS-niveau aan?

    Het MINFO-bericht zal, in tegenstelling tot de huidige situatie, de meetgegevens per PseudoGos bevatten. Hiervoor is binnen het PVE gekozen omdat de regionale allocatie per Pseudo-Gos plaatsvindt en de resultante hiervan (het LALL-bericht) dus ook per Pseudo-Gos wordt verzonden.
     

  • Kent GTS überhaupt de PseudoGos-indeling?

    Ja, GTS sluit namelijk transportcontracten met shippers af per Pseudo-Gos. De lijst met meetpunten (o.a. de Pseudo-Gossen) staat op de site van GTS.

TINFO-bericht

  • Is al bekend hoeveel temperatuurgebieden er in 2004 gebruikt gaan worden en zo ja, wat zijn de namen en de EAN-codes?

    Binnen PVE-verband is er voor gekozen in 2004 te werken met één temperatuurgebied. Dit gebied heeft de naam De Bilt gekregen en de EAN-code is 871718518990000019.

  • In de TINFO-berichten wordt in de definitie van het LOC-segment gesproken over temperatuurgebied. Kan ik hieruit concluderen dat een temperatuurgebied hetzelfde is als een regio?

    De definitie van temperatuurgebied is nog niet definitief bepaald. Er loopt nog een studie door bureau Ecofys; hierin wordt bepaald hoeveel temperatuurgebieden er nodig zijn. Dit zal waarschijnlijk varieren van 1 tot 4 temperatuurgebieden voor het gehele land.

  • En kan ik hieruit concluderen dat GtS temperatuurwaarden per regio (via een TINFO-bericht) naar de RNB stuurt?

    Als er wordt gekozen voor één temperatuurgebied krijgen alle RNB´s dagelijks hetzelfde TINFO-bericht. Als er meerdere temperatuurgebieden gedefinieerd worden, zal er voor ieder meetpunt (pseudo-Gos) moeten worden bepaald in welk temperatuurgebied deze zich bevindt. GtS zal dan TINFO-berichten per temperatuurgebied verspreiden aan de RNB´s.

  • Wordt een regio geïdentificeerd door een EAN-18 code?

    Een temperatuurgebied wordt geïdentificeerd met een EAN-code.

  • Indien het antwoord op de vorige vraag bevestigend is, is er dan al een lijst met EAN-18 codes gekoppeld aan regio´s?

    Er zullen te zijner tijd maximaal vier EAN-codes ter beschikking worden gesteld ter identificatie van het (de) temperatuurgebied(en).

  • Op pagina 11 (versie 0.5, 2003.05.02) in de DATA CONTENT staat achter 05 de ´temperature zone´ met een code. Is dit de EAN-code van het weerstation?

    Met ´temperature zone´ wordt hetgeen bedoeld dat in het PVE-eindrapport werkgroep 12 staat aangegeven als een temperatuurgebied. Een dergelijk temperatuurgebied wordt geïdentificeerd met een EAN-code. Nederland zal t.b.v. de profielberekeningen worden verdeeld in één of meer temperatuurgebieden. Hoeveel gebieden dit zullen worden, wordt bepaald in PVE-werkgroep 3 (wanneer is nog niet duidelijk).

  • Wordt het TINFO-bericht dagelijks of maandelijks verzonden?

    Dagelijks. De reden hiervoor is, dat een netbedrijf in geval van een switch of het reconciliatieproces iedere dag van de maand over de temperaturen van de lopende maand moet kunnen beschikken.

  • Hebben jullie ook bepaalde tijdstippen wanneer jullie (uiterlijk) jullie berichten versturen (MINFO en TINFO)?

    Uit eindrapport PVE-werkgroep 12: MINFO: Voor elk (pseudo-)GasOntvangStation levert GTS uiterlijk de 4e werkdag na afloop van de maand om 07:00 uur LET de volgende gegevens aan de RNB’s ....

    Het TINFO-bericht zal dagelijks door GtS worden verzonden. Door de onduidelijkheid t.a.v. de definitie van de temperatuurgebieden is er over het tijdstip van de dagelijkse verzending nog geen duidelijkheid.

Lall-berichten

  • In de diverse MIG´s wordt uitgebreid ingegaan op de inhoud van de berichten.Hoe moet een bericht worden aangemaakt?

    Deze informatie staat in het PVE-eindrapport werkgroep 12. Voor b.v. het LALL-bericht staat dit aangegeven in bijlage 2, paragraaf 5.1:
    Het netbedrijf dient de gegevens als volgt te clusteren:

    • het bericht voor de leverancier bevat de allocaties van de betreffende leverancier voor alle categorieën en voor alle shippers van een meetpunt;
    • het bericht voor de shipper bevat de allocaties van de betreffende shipper voor alle categorieën en alle leveranciers van een meetpunt;
    • het bericht voor LNB bevat de allocaties van alle shippers/leveranciers/categoriecombinaties van een meetpunt, m.a.w. alle allocaties van het betreffende meetpunt.

    Een ontvanger van een LALL bericht ontvangt dus altijd slechts 1 bericht per meetpunt (pseudo-Gos), waarin alle combinaties shippers/leverancier/categorie zijn opgenomen.

     

  • Moet een bericht per Gos (ed.)/meetpunt/pseudo-Gos de uurwaarden van een shipper/leverancier/profielcategorie of per shipper de uurwaarden per Gos/profielcategorie/leverancier worden aangeleverd?

    Logisch gezien worden er in 1 bericht één of meer combinaties van shipper/leverancier/profielcategorie opgegeven. Omdat we te maken hebben met de beperkingen van het EDIgas-bericht MSCONS zijn deze combinaties in het bericht op een iets andere wijze vormgegeven. Ze zijn er echter wel in aanwezig.

  • Klopt het dat de supplier identification (0170.NAD segment) voor elke gasdag wordt opgenomen?

    Dat klopt.

  • Wat is de reden om per gasdag de Leverancier op te nemen?

    Dit heeft te maken met de structuur die mogelijk is in een MSCONS-bericht. Het is inderdaad niet ideaal: 1 keer de leverancier noemen per combinatie shipper/leverancier/afnemercategorie -combinatie zou voldoende zijn. Omdat de tweede NAD (0170.NAD) zich echter binnen de LIN-loop van de gasdag bevindt, dient deze bij iedere gasdag opnieuw te worden opgegeven.

  • Kan ik per GOS/profielcategorie meerdere leveranciers in het bericht opnemen?

    Ja, b.v.:
    0100.NAD.1 Shipper: 1
    0110.LOC Meetpunt: PG Utrecht
    0130.RFF1 Categorie: GGV
    0170.NAD Leverancier: A
    ...............
    0130.RFF1 Categorie: GGV
    0170.NAD Leverancier: B
    ...............
    0130.RFF1 Categorie: GGV
    0170.NAD Leverancier: C
    ...............
    0130.RFF1 Categorie: GGV
    0170.NAD Leverancier: D
    ...............

  • Worden er eisen gesteld aan het ´message id´ dat wordt aangemaakt?

    Vanuit de LALL-edigas-spec is de syntax als volgt: DAYREPnnnnn, waarbij nnnnn een volgnummer is. Dit volgnummer moet uniek zijn voor de desbetreffende partij. Dus dit nummer in combinatie met de EAN-code is uniek identificerend.

Ball-berichten

  • Wordt er per GOS een apart BALL-bericht gestuurd naar de leverancier? O worden alle aansluitingen van een leverancier in één bericht verstuurd en is GOS slechts een kenmerk van de aansluiting?

    In het BALL bericht komt het GOS niet (meer) voor, alleen de identificatie van de aansluiting. De leverancier wordt geacht de inhoud van het aansluitingenregister te kennen en dus te weten achter welk (pseudo-)Gos zich een aansluiting bevindt.


    Er mogen meerdere aansluitingen in een BALL-bericht worden samengevoegd. Het is niet noodzakelijk alle aansluitingen achter een (pseudo-)Gos in 1 BALL-bericht te verzenden. Het is natuurlijk wel toegestaan.

CINFO-bericht

  • Wanneer moeten jullie de PALL- en CINFO-berichten uiterlijk binnen hebben? Dat staat niet expliciet in de meetcode.

    GTS ontvangt het PALL bericht niet (dit wordt alleen naar de leverancier verzonden).
    Voor het CINFO-bericht gelden dezelfde tijdstippen als voor de allocatieberichten BALL en LALL, te weten: op de zevende werkdag, 00:00 uur LET (versie 1) en de zeventiende werkdag, 00:00 uur LET (versie 2). Zie ook hiervoor het eindrapport PVE-werkgroep 12.

Pall-berichten

  • Indien de PALL-berichten voor ons van geen belang zijn, moeten wij dan Edine-toepassingen installeren/testen?

    De PALL-berichten worden verzonden naar leveranciers van profielafnemers. Als u deze rol niet vervult, zullen de RNB’s het PALL-bericht dus niet naar u sturen. Er is dan ook geen noodzaak voor u om dit bericht te implementeren.

Dagallocatie

Dagallocaties.pdf pdf (57kb)