BEAst
Medlemswebb (Till BEAst Portal)
Sök

Frågor och svar om NeC

Support för införande av standarden

För att underlätta för de som ska införa standarden NeC redovisar vi svaren på de frågor som skickats in till BEAst om tillämpning av NeC. Du som har ytterligare frågor kan ställas dem till .

Former för e-faktureing

Fråga: Hur ska fakturering ske, per projekt med överenskommen periodicitet eller per avrop (order)?

Svar: När ett åkeriföretag ska skicka en faktura till en bygg- och anläggningskund ska fakturan alltid avse ett projektnummer. På sikt tror vi att kunderna kommer att vilja ha en faktura per avrop för att kunna automatisera sin fakturahantering så mycket som möjligt. Där är vi dock inte än. Under en period kommer många att vilja ha samlingsfakturor, t.ex. per vecka eller månad. Det ska dock alltid vara per projektnummer. Om fakturan ska avse ett eller flera avrop måste, åtminstone tills vidare, vara en fråga för köpare och säljare att komma överens om.

Landskoder i standarden

Fråga: Vilken typ av kod ska det vara för att ange landskod i meddelandena. Om det är en 2-ställig kod, varför är det då 3 tecken tillåtna enligt NeC?

Svar: När vi tar fram standarder i BEAst baserar vi dem alltid på UN/CEFACT, som också finns som ISO-standard (finns flera olika). För dataelement är standarden från Cefact ”UNTDED” och det är den internationella standarden för dataelement. Om jag kommer ihåg rätt heter den ISO7372. I den är värdet för landskod tre tecken. I stort sett alla kodvärden i elementkatalogen har längden ”upp till tre tecken”. Inom BEAst sätter vi ett termnummer på alla element vi använder och sedan används samma term i alla meddelanden där det är relevant. Jag kan förstå att du tycker det är ologiskt med tre tecken i det här fallet, men vi vill basera oss på den internationella standarden.

Prestandadeklarationer

Fråga: Från 2013-07-01 gäller ett EU-direktiv som föreskriver att en leverantör av anläggningsmaterial ska redovisa en prestandadeklaration för det som levererats. Hur hanteras det i NeC.

Svar: Är uppdaterat från version 1.1 av standarden.

Ansvarsöverlämning

Fråga: Det finns olika standardavtal för att definiera hur ansvaret för en leverans av anläggningsmaterial överförs från leverantör till kunden. Hur hanteras detta i NeC?

Svar: En förutsättning för att använda standarden är att det finns ett avtal mellan parterna där man gjort upp om priser, leveransvillkor etc. Vad det är för avtal eller standardavtal tycker vi inte har med standarden att göra, utan är en kommersiell fråga för köpare och säljare att komma överens om.

Orderkvitto och rader

Fråga: I avropet kan man ha många avropsrader, men i Orderkvittot ligger fält T6336 ”Ref till Avropsrad” på huvudnivå på OrderKvittot (dvs inte på radnivå). Är det meningen att det ska skickas ett Orderkvitto-meddelande per Avropsrad som fanns i Avropet?

Svar: Ett avrop kan bestå av en eller många rader och vara utspritt över lång tid. Orderkvittot däremot ska skickas direkt när ett uppdrag, avropsrad, är genomfört. I många fall blir det bara en rad i orderkvittot, men det kan också finnas mer än en rad. Första raden i Orderkvittot avser kanske materialet som levererats, den andra raden ett tillägg för stillestånd och en tredje för antalet körda mil. För varje rad finns möjlighet att lägga in antal, artikelnummer, pris etc.

Sammansatta artiklar

Fråga: Det finns artikelregister för material och transporttjänster för att identifiera artiklar som avropas med NeC-standarden, men hur är det med artiklar som inkluderar både material och transporttjänst?

Svar: Vid ett avrop så anger köparen i varje avropsrad den artikel som ska avropas. Artikeln kan vara en transporttjänst eller material och för dessa områden finns det standardiserade artikelregister från olika branscher (Sveriges Åkeriföretag, SBMI, etc) som rekommenderas för användning i NeC. Före kunden kan börja lägga avrop ska parterna ha kommit överens om ett avtal och i det avtalet ingår ofta transporten i priset för materialet. Det innebär att man använder artikelnumret för materialet enligt aktuell branschs artikelregister och att det i det här fallet ingår både material och transport.

Om man vill beställa ett fordon som har ett högre pris än det som ingår i avtalet så finns det i avropsmeddelandet på radnivå en tagg som heter ”Alternativ fordonstyp” som finns i standarden från version 1.1.

Avropsrader

Fråga: Standarden kan innehålla flera avropsrader, t.ex. transport, material och tillbehör vilket skulle bli tre avropsrader i meddelandet. Varför finns det på varje avropsrad en avsändaradress och en mottagaradress samt eller leveranstillfälle? Borde det inte vara det samma i samma order/uppdrag?

Svar: När en entreprenör lägger ett avrop så kan det avropet leda till flera order i åkeriets system. En rad kan vara ett lass grus med en viss leveranstid, nästa rad ett annat uppdrag som ska levereras en annan tidpunkt som förmodligen är till samma ställe men det kan ibland vara olika internadresser på arbetsplatsen.

Relation Avrop-Order-Vågsedel-Orderkvitto

Fråga: Hur är relationen mellan dessa meddelanden?

Svar: Ett avrop från kunden består av en eller flera avropsrader. Varje rad kan vara t.ex. en lastbil som ska köra ett eller flera uppdrag vid ett tillfäller eller för en period. I åkeriets system skapas en order per avropsrad. Viktigt är att i de följande meddelandena för bekräftelse, vågsedel, orderkvitto och faktura referera till kundens avrop och avropsrad. Varje körning inom en avropsrad genererar en vågsedel. Orderkvittot kan bestå av en eller flera körningar för en överenskommen tidsperiod, t.ex. en dag, för ett projekt och för ett fordon.

 Manuella avrop

Fråga: Hur ska man göra om ett avrop sker manuellt per telefon, blir hela ärendet då manuellt?

Svar: Det går aldrig att få 100% digitala avrop. När så sker rekommenderar vi att orderkvittot skickas när uppdraget är slutfört. I version 1.2 av standarden finns referenser som gör att kunden ändå kan få referens till rätt uppdrag.

BEAst AB - Byggbranschens Elektroniska Affärer. Mötesplats - Standardisering - Utvecklingsprojekt
| Producerad av Construct IT | © 2017 BEAst