NYT I SONWIN RELEASE NOTES. SONLINC A/S Copyright 2016 PRINCE2 is a registered Trade Mark of the Cabinet Office

Transkript

1 RELEASE NOTES NYT I SONWIN /90

2 INDHOLDSFORTEGNELSE 1 Forord 3 2 Erfa-opgaver og andre større nyudviklingsopgaver 3 3 Vigtige ændringer til SonWin Afregning og fakturalayout Markedskommunikation og Markedssync Integration 11 4 Øvrige ændringer til SonWin Distribution og Målere Afregning og fakturalayout Debitorstyring og Kundeservice Det Frie Marked Integration Basis 24 5 Apendix SonWin Host: Opsætning af DTC Distributed Transaction Coordinator Databaseændringer 32 2/90

3 1 Forord Dette dokument indeholder en beskrivelse af de generelle nyudviklinger, som er leveret til: SonWin Billing Server SonWin Billing Client SonWin Invoice Engine, SWIE SonWin Server Invoice Renderer, SWIR SonWin Server NetsComm, SNEX SonWin Server NetsXML SonWin Server Customer Consumption Point Search, AWK SonWin Server Customer Search, AWK SonWin Server CustomerService Flows, AWK SonWin Market Server SonWin Server Market Sync SonWin Market Communicator SonWin Server Market Server, Engrosmodel SonWin Server Market Communicator, Engrosmodel SonWin XMLBasis SonWin Host SonWin Host Client Fra release til og med release Erfa-opgaver og andre større nyudviklingsopgaver I dette afsnit står Erfa-sager og de andre større nuudviklingsopgaver. Sagsnummer: ahawk - Nyt skærmbillede til overblik og opfølgning på kundeflows Nyt skærmbillede til overblik og opfølgning på kundeflows delleveres med denne release alle søgemuligheder er implementeret. Til release leveres funktionerne til de knapper, som vises på højre side af skærmbilledet under Handlinger. 3/90

4 Sagsnummer: Rbal02 Optimeringer ifm. implementering af rbal02 (EL/GAS) (NET) Nedenstående udvidelser til rbal01, rbal02 og balog er implementeret i dette Erfa-tilbud. Rettelser: 1. Swakt, swservadm og balog er udvidet, så man kan se hvilke rapporter (rbal01 eller rbal02), der behandler de respektive planer, og i forbindelse med rbal02 også at kunne se, hvilket trimningsnummer rbal02 behandler. Herved bliver det lettere at danne sig et overblik over hvilke planer, der behandles af hvilke rbal01 og rbal02 rapporter. 2. Søgemuligheden i balog er udvidet, så man kan søge på tidspunkter i stedet for kun dage. 3. Fejl ved beregning af tidsserieformler og godkendelse af tidsserier (startet fra baplan) vises let og overskueligt i balog. Herved bliver fejlfinding i beregning af tidsserieformler og godkendelse af tidsserier nemmere og hurtigere. Rettelser er lavet i både SonWin Billing Client og SonWin Billing Server. Sagsnummer: Batidsnr Udvidelse af antal decimaler i feltet Omregn. Enh. (EL/GAS) (NET/LEV) Tidligere var det kun muligt at angive 3 decimaler efter kommaet i feltet Omregn. Enh.. Rettelse: Der er nu lavet udvidelse, således at det nu er muligt at angive 6 decimaler efter kommaet. Sagsnummer: Omstrukturering af den tabel der indeholder tidsserierne Den sidste del af dette Erfa-tilbud er nu færdig og leveres med Release /90

5 SonWin benytter hermed ikke længere [Sonlinc].[BATIDSERIE] som View. View et vil ikke blive fjernet som en del af reorganiseringen, da der fortsat kan være steder, hvor kunder benytter viewet fx i rapporter dannet via Reporting Service. Sagsnummer: Visning af CPR-nummer I Release blev det ændret, således at de sidste fire cifre i CPR-nummeret blev x et ud i alle de funktioner, der viser CPR-nummeret. Efterfølgende har der været et stort ønske om, at udvalgte medarbejdere kan se CPRnummeret. Der er derfor foretaget en justringen til skærmbillederne akunde og mkunde, så man kan sætte op hvilke medarbejdere, der skal kunne se CPR-nummeret. Dette gøres ved at give medarbejderne adgang til skærmbilledet CPRVISNING med autoritet på mere end 9 i funktionen swfunk. På den måde er det ikke autoriteten til skærmbillederne akunde og mkunde, der bestemmer om man kan se CPR-nummeret, men en generel autoritet. Sagsnr Arykluk oversigtskærmbillede Første version af nyt oversigt skærmbillede arykluk medtaget, som beskrevet i produktbeskrivelse. Billedet kan bruges til at overvåge rykkere og til at sende beskeder til elmarkedet. Beskrivelse kan også findes i F1 hjælp. Obs: Når man bruger knapperne til leveranceophør og afbryd, så skal det gøres med forsigtighed og med fokus på at validere de valgte installationer. Ved at bruge autoritetskoder kan adgang til at bruge disse knapper begrænses (se evt. F1 hjælp). Brugerne skal være opmærksom på, at det er den korrekte aktive forbruger, der er valgt. Det er vigtigt at sikre, at der ikke er flyttet en ny forbruger ind på målepunktet, og det er den forrige forbruger, der udløser en lukning. Det er vigtigt at tjekke, om der fremgår en dato i kolonne 5/90

6 Stopdato. Hvis dette er tilfældet, bør man ikke leveranceophøre/afbryde, men derimod undersøge forholdet. Obs: I testen har vi set problemer med knappen til Genanmod om Leveranceophør. Derfor er den blevet de-aktiveret. Den vil blive aktiveret igen ved næste release. Sagsnummer: mmpprislist Rapportudtræk på skabeloner, målepunkter og PrisID er (EL) (NET/LEV) Første del af Erfa-tilbud på sagsnummer er nu leveret. Delleveringen indeholder det nye skærmbillede mmpprisliste. Sidste del af tilbuddet vil blive leveret i , og indeholder udvidelsen til mprislist. Mmpprislist vil kunne give følgende overblik: 1. Antal målepunkter tilknyttet pr. skabelon 2. Hvilke målepunkter, der er tilknyttet pr. skabelon 3. Antal målepunkter pr. priselement (dvs. hvor mange målepunkter, der har et aktuelt priselement tilknytttet) 4. Hvilke målepunkter, der har et aktuelt priselement tilknyttet 5. Målepunkter, der mangler priselementer 6. Målepunkter, der mangler skabeloner 7. Målepunkter, der har priselementer, der er kladder 8. Målepunkter, der har priselementer, der er afvist For yderligere information henvises der til produktbeskrivelsen på sagen og F1-hjælpen. 3 Vigtige ændringer til SonWin I dette afsnit står de vigtigste fejlrettelser. 3.1 Afregning og fakturalayout Sagsnr SWIE: Mulighed for ændring for slutopgørelser. TR kan nu også anvendes til slutopgørelser. Ved slutopgørelse forstås, at leverancen ikke længere haves, og at der ikke er nogen forsyningsarter, der skal afregnes i efterfølgende periode. TR er de trimninger, hvor i grænsen for opkrævning sættes nu både for slutopgørelse og flytteopgørelser. Før denne release har trimningerne kunne anvendes til flytteopgørelser. Er TR-6012, KUNFLYT er sat, gælder TR kun for flytteopgørelser. Slutopgørelse vil så altid blive opkrævet, også hvis fakturabeløbet er inden for grænsen. Er TR-6012, KUNFLYT ikke sat, afskrives fakturabeløb for både slutopgørelse og flytteopgørelser, hvis fakturabeløb ligger i grænseområdet. Det er derfor meget vigtigt at kontrollere, hvilke trimninger der er sat, og om der ønskes at ændre i denne opsætning. TR-6012, DANADVIS er udfaset af SWIE. 6/90

7 Rafr69_v4 er tilrettet SWIE beregninger, således at betalingstekst på forsiden svarer til TR Sagsnr Kan ikke starte beregningskørsel UDEN SWIE Det er tidligere blevet indført, at alle beregninger skal udføres i SWIE. I den forbindelse er der enkelte selskaber, som ikke kan udføre korrekt beregning. Det er derfor indført i SWIE, at man kan anvende fordeling på aconto på varme efter AGRAD. Dette kan aktiveres per afregningstype med bchec-koden SWIE, PERVARMEAGRAD med fortløbende nummer i koden og afregningstype i kodetekst. Husk, at SWIE, EKSKLAFREGNTYPE skal fjernes for, at SWIE kan medtage en afregningstype i en kørsel. Sagsnr DGF kontrakter modregnes ikke på Netto.Grp6 Logikken til acontomodregning af tarifarter, som ikke indgår i tariffen, antog, at bchec-koden SWIE, DIVERSEDELNR er sat. Workaround: sæt SWIE, DIVERSEDELNR, 999. Det er rettet i SWIE, således al modregning sker, hvis bchec-koden ikke er sat! Sagsnr Rafr69_v4 til engrosfaktura Summerede fakturalinjer, der udligner hinanden næsten, men bliver vist med forkert meget stor á pris, er rettet således, at hvis á pris er næsten 0, på 6 decimal, så afrundes til 0. Det kan anbefales, at også trimning til afgrænsning af decimaler på antal sættes pr. tarifart. RAFR69_V4, AFRUNDTARIFART, tarifart sættes i kodetekst, antal decimaler sættes i kr/pct. Der oprettes en linje pr. tarifart, og der tælles op på koden. Sagsnr Ændring af priser på EL-handelskontrakter og visning af kontrakt i rafr69_v4. For handelsselskaber, til visning af kontrakt i layout rafr69_v4 efter engrosmodellens ikrafttrædelse, er det vigtigt at dette læses. Ved opdatering af priser på bakontr, gældende for EL. For at sikre, at alle linjer/priser bliver opdateret med visning af kontrakt på layout, er det vigtig, at denne procedure følges: 1. Når tekstnr og evt. sti til logo er sat, fjernes begge og der gemmes (F3) 2. Hak i kontrakt på layout fjernes, og der gemmes igen (F3) 3. Nu er alle linjer clearet, og nye priser oprettes 4. Efter, at alle priser er oprettet, kan hak i kontrakt på layout sættes, og der gemmes (F3) 5. Tekstnr og evt. sti til logo sættes, og der gemmes (F3) Alle kontraktpriser er nu opdateret med samme information om visning på layout. Er der ingen information om visning på layout, på bakontr, oprettes denne information efter prisopdatering, og der gemmes(f3). Alle priser bliver automatisk opdateret med valgte information til brug i rafr69_v4. 7/90

8 3.2 Markedskommunikation og Markedssync Sagsnummer: Sync af ændringer til eksisterende leverandørforhold til ampop (EL) (LEV) Følgende ændringer er blevet implementeret i Sync en. Når en slutdato slettes (enten manuelt eller via markedkommunikationen): Sync en sender en besked til ampop om at åbne leverancen. Når der sættes hak i annulleret (enten manuelt eller via markedkommunikationen): Sync en sender en besked til ampop om at lukke den leverance, der ved en fejl var opstartet. Ovenstående ændringer medfører, at fejlagtige flytninger og fejlagtige leverandørskifter nu vil ende med at have korrekt leverandørforhold i ampop. Sagsnummer: Tidsserier Manglende indlæsning af tidsserier (EL) (NET/LEV) Det er konstateret, at nogen tidsserier ikke indlæses, hvilket efterlader huller i tidsserierne. Når problemet opstår, ses denne besked i mfejl: Rettelse: Problemet viste sig at opstå hver gang, der blev modtaget dubletværdier (dvs. samme MALEPUNKT, samme TSnr, samme døgn) i samme besked fra DataHub en. Sync en kunne ikke aflevere dubletværdierne korrekt til komponenten, der gemmer værdierne i tidsserien korrekt, og dermed fejlede hele indlæsningen af alle værdier (dvs. hele bundtet), der blev forsøgt håndteret sammen med dubletværdierne. Dermed kunne tidsserier uden dubletværdier også sagens blive ramt af fejlen. Fejlen er nu løst. Løsningen gælder ikke med tilbagevirkende kraft, og det er derfor nødvendigt selv at dække de huller, der måtte være pga. denne fejl ved at genanmode om de manglende døgn. Sagsnummer: Sync D01 D33 rydder ikke korrekt op i leverandørforholdet (EL) (LEV) Ved fejlagtig tilflytning, hvor man både har leverancen til den (fejlagtige) tilflytter og fraflytter, modtages E44 D34 og D01 D33. Meningen er at modtagelse af E44 D34 bør medføre: Markering i annullering på start leverancen, og modtagelse af D01 D33 bør medføre: Sletning af stopdato på den gamle leverance. Ovenstående håndtering sker korrekt i scenarier, hvor leverandøren til (fejlagtig) tilflytter og fraflytter er forskellige. I scenarier, hvor leverandøren er ens på både tilflytter og fraflytter, medfører modtagelsen af D01 D33 dog ikke sletning af den gamle stopdato som forventet, hvilket medfører, at den nye (fejlagtige) leverance annulleres, mens den gamle leverance forbliver lukket i SonWin, selvom den er åben i SonWin. Rettelse: Det er rettet, således at modtagelse af D01 D33 nu medfører en sletning af stopdato på den gamle leverance, selvom der ligger en nyere leverance med hak i "annulleret". 8/90

9 Sagsnummer: Sync Fejl i nummerering af Virtuelle målere (NETTO), hvis der er flere forsyningsarter (EL) (LEV) Ved modtagelse af målepunkter, via DataHub en på solcelleanlæg, får den virtuelle måler et forkert målernr, da den ikke tager højde for, at der kan være flere forsyningsarter på en installation. Rettelse: Der kigges nu på FORSYNART på de eksisterende målere. Logikken bruger kun NULL eller 0 som indikation på el. Det vil sige, at nettomåleren kommer til at ligge lige efter sidste el-måler. Sagsnummer: Rbal02 Dannelse af 0-værdier går i stå (EL) (NET) Igangsættelse af RBAL02 medførte i nogle tilfælde, at Dannelse af 0-værdier blev startet, men aldrig blev færdig. Rettelse: Der var en fejl, der medførte en uendelig løkke, og derfor ville opgaven aldrig blive færdiggjort. Fejlen er nu rettet. Sagsnummer: mforbtaller Modtagelse af sletninger hvor original ikke findes (EL) (LEV) Modtagelse af annulleringer af forbrugsopgørelser, hvor original aflæsninger ikke findes på MFORBTALLER, virker ikke. Rettelse: Rettelse er nu lavet det er implementeret således, at hvis der modtages en annullering, hvor der ikke findes en original i forvejen, så indsættes en 'original' som markeres som slettes. Den originale, som bliver indsat, bliver ikke sync'et til ATLV/EVNTS. Sagsnummer: Forbrug Der skal bruge SKØN-kode på estimeret aflæsninger (EL) (LEV) Når der modtages estimeret aflæsninger, skal aflæsningskoden være "skøn-koden" fra bchec i stedet for EDI/default-kode. Rettelse: SKØNKODE bchec bliver nu brugt ved modtagelse på leverandørssiden, når estimeret aflæsning skal indsættes på ATLV/EVNTS. BCHEC'en der skal bruges hos er: KODENAVN KODETYPEA KODETYPEN SWMARKET SKØNKODE 0 KODETEKST [ønsket aflæsningskode] Hvis denne bchec sættes, indsættes estimeret aflæsninger med denne kode i stedet for EDIkoden på atlv via Sync en. Rettelsen virker ikke med tilbagevirkende kraft. De estimerede aflæsninger, der tidligere er modtaget, kan udsøges i mforbtaller. Til information kan samme SKØNKODE bchec bruges på netselskabet, hvor det får den betydning, at aflæsninger med aflæsningskoden, der står i bchec en sendes som en estimeret/skønnet aflæsning til DataHub en. Denne logik er ikke ny. 9/90

10 Sagsnummer: Aflæsningsfrekvens Ændring i regler for default aflæsningsfrekvens (EL) (NET undtagen BEOF) De aflæsningsfrekvenser som bliver sat som default, skal ændres. Reglerne som der har været hidtil var: - E17: Afhængig af afregningsformen. - Skabelonafregnet = Andet. - Timafregnet = default fra mparti. - E20, E18, D05, D06, D07, D14: Default aflæsningsfrekvens jf. mparti - De resterende D-typer: PT1H Ovenstående regelsæt medførte forkerte oprettelser af D14 og D07 målepunkter, som efterfølgende manuelt skulle have tilpasset aflæsningsfrekvensen. Det samme problem blev set på E18 i gr. 1 og gr. 2 som altid skulle være aflæsningsfrekvens = timeaflæst. Rettelse: For at forhindre den manuelle eftersending af opdatering af aflæsningsfrekvensen, er default reglerne for aflæsningsfrekvens nu ændret til følgende: - E17: Afhængig af afregningsformen. o Skabelonafregnet = Andet. o Timafregnet = default fra mparti. - E20, D05, D06: Default aflæsningsfrekvens jf. mparti - De resterende D-typer (herunder D07 og D14): PT1H - E18 i gr. 0 = Default aflæsningsfrekvens fra mparti - E18 i gr. 4 = PT15M. - E18 i gr. 1 og 2 = PT1H Gruppe 5 og 6 har ikke E18, derfor optræder problemet ikke. Hvis der alligvel oprettes en E18 i gr. 5 eller 6 (det tillades i markedsreglerne, selvom det ikke giver mening), vil aflæsningsfrekvensen blive sat til default fra mparti. Sagsnummer: Forbrug NETTO-måler får forkert opsat-stand (EL) (LEV) Når NETTO-måleren autooprettes indsættes en fiktiv opsat-stand. Datoen for denne opsatstand udvælger Sync en, ud fra dette regelsæt: - Hvis der allerede findes en aktiv måler (som ikke har målerart = NETTO), benyttes seneste aflæsningsdato fra denne målers tælleværk 1 som datoen for opsat-standen, med mindre datoen ikke matcher den periode, der forsøges indlæst i så fald benyttes startdatoen på perioden (-1 dag) som datoen for opsat-stand. - Hvis ikke der er en aktiv måler, benyttes startdatoen på perioden (-1 dag) som datoen for opsat-stand. Dette princip er ens uanset, om der er nettoafregning eller ej. Dette kunne medføre en forkert opsat-stand på NETTO-måleren og dermed problemer med at sync e efterfølgende forbrug. Rettelse: Fra vil der blive ændret i håndteringen af opsat-stand, så datoen for opsatstand altid er lig seneste aflæsning på den aktive (fysiske) måler, i stedet for startdatoen på perioden (-1 dag), med mindre der har været et leverandørskifte i mellem. Hvis ikke der er en aktiv måler, benyttes startdatoen på perioden (-1 dag) som datoen for opsat-stand. Opsat stand vil i begge tilfælde være lig 0 i forbrug og stand (stand kendes ikke da det er en virtuel måler!). 10/90

11 Sagsnummer: Mkunde E44 E65 bør ses som HasBalanceSupplier=true (EL) (NET) Det er blevet foreslået, at det skal være muligt at sætte en måler op, selvom der kun ligger en tilflytningsbesked (E44 E65), da vi ikke nødvendigvis får den kundestamdata besked som forventes for, at målepunktet bliver markeret som at have en leverandør. Ved modtagelse af E44 E65 oprettes der derfor nu en mkunde "skal" hvor HasSupplier = true, hvis der ikke er en kunde. Denne sync es til ampop, og måleren kan derfor sættes op, selvom kunden endnu ikke er modtaget. Sagsnummer: BRS-014 / BRS-007 / BRS-001 Oprettes ikke ny måler ved levskift (EL) (LEV) Ved tilbagevender oprettes ikke ny måler ved levskift/flytninger, hvis den gamle måler er inaktiv. Der SKAL oprettes ny måler ved levskift/flytninger på tilbagevendere, hvis det målepunktsstamdata, der modtages indeholder et målerid, der er forskelligt fra den måler, der i forvejen findes på amal. Rettelse: Når vi modtager målepunktsstamdata på en tilbagevender, så kontrolleres om målerid er ændret i forhold til den inaktive måler fra sidste leverance. - Hvis målerid er skiftet, så opsættes ny måler og tilhørende tællerværk. - Hvis målerid er uændret, så genaktiveres den gamle måler og tilhørende tælleværker ved at sætte STATUS2N til 1. Sagsnummer: Forbrug Automatiserede annulleringer af aflæsninger, der ikke er afregnet (EL) (LEV) Der var et ønske på Erfa-seminaret i oktober fra kunderne om, at annulleringer af aflæsninger, der ikke er afregnet automatisk, slettes på atlv. Fortsat manuelt håndtering af aflæsninger, der ER afregnet. Rettelse: Hvis der ikke ligger nogle fejlende eller manglende manuelt håndteret annulleringer, så bliver annulleringer forsøgt sync'et in på EVNTS. Hvis der er regningsnummer på, så vil den automatiske sletning fejle, og den skal håndteres manuelt, og efterfølgende markeres på MFORBTALLER, ligesom før. Hvis der ikke er regningsnummer på, slettes aflæsningen manuelt. 3.3 Integration Sagsnummer Optimering af SonWin Host OBS inden installation af version 11 af SonWin Host Hvis systemets Billing database kører på en anden database server end den database server, hvorpå Host databasen ligger, så skal der efter version 11 af Hosten køres med linked servers samt med distributed transactions se mere i afsnittet omkring opsætning af linked servers. Runtime brugeren SonlincAppl_SWHost_Sonlinc skal efter version 11 af Hosten have rettigheder til at oprette og slette temp tabeller, samt til at oprette temp indekser. 11/90

12 Opsætning af Linked server Hvis Billing databasen kører på en anden database server end den hvorpå Hostens database ligger, så skal der opsættes et link fra den database server hvorpå Hostens database ligger, til den database server hvorpå Billing databasen ligger. Ud over opsætning af linket, skal der også køres med distributed transactions imellem de to database servere. Dette er for at sikre korrekt håndtering af transaktioner i forbindelse med overførsel af data fra Billing databasen til Hostens database. Oprettelse af link Linket, fra Hostens database server til Billing databasens database server, skal oprettes på Hostens database server. Linket oprettes ved at køre de to nedenstående stored procedures på Hosten database server. EXEC DATABASE SERVER>' GO EXEC '<BILLING DATABASE = = = '<PASSWORD>' GO <LINK NAVN> kan frit vælges. Det er et symbolsk navn, som bruges til at udpege linket til Billing database serveren. <BILLING DATABASE SERVER> Er navnet på Billing databasens database server. Den database-bruger, der bruges i forbindelse med oprettelsen af linket, skal have samme rettigheder, som SonlincAppl_SWHost_Sonlinc brugeren har på Host databasen. For mere information omkring opsætning af linked servers se OBS! For opsætning af DTC Distributed Transaction Coordinator se Apendix på side 26 12/90

13 4 Øvrige ændringer til SonWin I dette afsnit står de øvrige fejlrettelser og lukkede mangler. 4.1 Distribution og Målere Sagsnr Ampop og Amalo F-taster F-tasterne kan nu bruges på ampop og amalo. Sagsnr Amalo to tælleværker Når der på en installation, med en måler med et tælleværk, skiftes måler på Amalo, kan den nye måler nu have to tælleværker. Sagnr Rafr20 For netselskaber: Når rafr20 bliver kørt med hak i "Rokering af ikke rokederede" kom de installationer, der er gået godt med i sprint. Dette er ændret til, at der er de installationer, der ikke blivet rokeret, der kommer i sprint + det antal der er gået godt. Sagsnr Ainst Felterne BBR til/fra er fjernet fra ainst. Forespørgslen fra Lev til Net håndteres af AWK'en. Netselskabet styrer via ampop - Lev ser info via ampop. Sagsnr Rafr04 Der er nu mulighed for at vælge forsyningsart, når der skal udskrives selvaflæsningskort via rafr04. 13/90

14 Sagnr Målepunksid på ampop I instnr på ampop kan der skrives målepunksid og trykkes enter/f4/udsøges og installation bliver fundet og vist i ampop. 14/90

15 4.2 Afregning og fakturalayout Sagsnr Bedre tekst i info.journal ved manglende timedata Teksten i informationjournalen er udvidet til at skrive mpid samt fra og tildato for den periode, hvor SWIE konstaterer, der mangler godkendte timedata. Sagsnr Laver aconto el, selvom vi ikke har kunden længere Der er generelt ikke kontrol imod leveranceforhold (GLN) på ampop ved aconto. I eksemplet på sagen, er der ikke modtaget en aflæsning på lev.skiftedatoen, og da der er tale om en produktionskørsel, så vil der dannes en aconto. Men der er nu lagt en spærring ind i SWIE, således der ikke beregnes aconto, hvis der er et stop på leverancen indenfor den opkrævede acontoperiode. Der bliver beregnet en leverandørskifteopgørelse, når en aflæsning er modtaget. Sagsnr Mange installationer, hvor samme periode afregnes flere gange Fejlberegningen sker, fordi der er lagt nyt tælleværk ind med opsat aflæsning, der ligger senere end den dato, som el er opgjort til og med. Dette forvirrer overgangen mellem gammel og ny logik ifm. Engrosmodellen. Opsat datoen skal derfor ændres på det nye tælleværk. Der er dog indlagt en fejlbesked i SWIE, som tager højde for denne situation. Derfor er sagen lukket som en fejlsag, selvom der egentlig er tale om en datafejl. Sagsnr SOL og ELSOl er gennemsnit SWIE er ændret, således der ikke dannes flere sæt AEL linjer ved prisskifte i aconto/opgørelsesperioden. Dobbelt AEL linjer medførte beregningsfejl på gennemsnitsprisen i RAFR69v4, da layout dermed troede, der var dobbelt så stort et forbrug. Sagsnr Korrektionsberegning NED databasen Der er indført beskeder i informationsjournal ved fejl i en korrektionskørsel. Hvis der pga. cleancut ikke findes en underdebitor i perioden for en korrektionsaflæsning, så meddeles dette i informationsjournal. Derudover er der lavet ændringer, så følgende bliver medtaget i korrektionsberegning nulpris-linjer aflæsninger med aflaskode 5 aflæsninger, hvor forbruget korrigeres til nul enheder for afregningsperioden Sagsnr Problemer med beregning af forbrug år-1 Det er rettet, så korrigeret forbrug ikke fejlagtigt kan komme til at tælle dobbelt ved beregning af forbrug år-1 på varme. Sagsnr Beløb overført på levskifte opg. Der er indført TR-601 og TR-602 kontrol (straksafskrivning af småbeløb på faktura ved flytteopgørelse) på ren lev.skifteopgørelser. Bemærk, bchec koden TR-6012, DANADVIS bliver ikke anvendt i SWIE. 15/90

16 Sagsnr forkert dato på OVFKR linje pga kontrakt Ændret, således APRIS linjer - som ikke medtages på regningen pga ejnulprisart opsætning - ikke kan påvirke de generelle fra og til datoer på A-TOT,OVTKR,OVFKR linjer. Sagsnr Afregning af 2 produktionstlv fejler Lagt ændring ind i SWIE, så der ved ikke-fysiske målepunkter på en nettoafregnet ikke forventes aflæsninger. Beregning på et målepunkt uden fysisk tælleværk kan således kun ske baseret på tidserie. Sagsnr Forkert forfaldsdato (SE S ) SWIE tjekker nu ved loopkørsel, om bestilt forfaldsdato fra fx kundeflow servicen er inden for forfaldsdatoperioden i PERIO. Falder forfaldsdato uden for PERIO, vil SWIE i stedet falde tilbage til ABETBET forfaldsdatoberegning. Er der ingen indstillinger i ABETBET, vil SWIE i stedet bruge forfaldsdato fra RAFR01 bestillingsskærmbilledet. Er der ingen forfaldsdato i RAFR01, bliver det blive meldt ud i informationsjournalen, og beregning af installationen stoppes (STOP bliver sat). 4.3 Debitorstyring og Kundeservice Sagsnr Indbetaling går i fejl TR-DUBDEB og RAFR07, INDLASREGNR tager ikke højde for at kreditnota kan være tilstede, derfor findes forkert regningnr, og der kan ikke posteres korrekt. Indbetaling går i fejl. Der er rettet således at der tages højde for at faktura kan være krediteret. Sagsnr Kan ikke afslutte depositum med delindbetaling Det er nu muligt at annullere et depositum, hvor der er sket en del indbetaling, og dette er udbetalt, så saldo er 0 kr. (reglerne for at annullere deposita tillod ikke dette i tidligere versioner). Sagsnr Udfyldelse af MPID i awk Når der laves tilflytning i awk på eksisterende installation, blev målepunktsid og produktionsid med samme værdi. Nu bliver målepunktsid udfyldt med E17 fra ampop og produktionsid udfyldes med E18 fra ampop, hvis der er en E18 i ampop. Sagsnr awk opdaterer ikke feltet xpostnummer Nu blive begge felter postnr. og xpostnummer udfyld med samme værdi. Sagsnr Forfaldsdato på flytteopg skal styres fra abetbet Forfaldsdatoen sættes således: Hvis kunden er tilmeldt BS, vil forfaldsdatoen være den samme dato som PBSFRISTNESTE fra tabellen VIRK. Hvis kunden ikke er tilmeldt BS, vil forfaldsdatoen beregnes udfra abetbet. Hvis abetbet ikke er opsat, vil forfaldsdatoen pr. default sættes til 14 dage fra skæringsdato i awk. 16/90

17 Sagsnr Flytteflow gik i stå på CreateSubdebitor Flowmotoren opfattede status2n = 2 på ainsd som inaktiv og stoppede ved CreateSubdebitor. Dette er nu rettet. Sagsnr Alm flytning kan ikke overskrive sekundær flytning Flowmotoren ville ikke gennemføre en almindelig tilflytning efter at en sekundær tilflytning var blevet gennemført. Det er nu rettet. Sagsnr Søgninger efter kunde eller installation fik timeout i awk Timeoutværdien er blevet forøget, således at awk venter længere på et svar fra søgeservice. Sagsnr Kan ikke gennemføre en flytning i awk efter annullering i aopff Hvis man forsøgte at lave en flytning på en installation, hvor der ligger en annulleret flow i aopff, fik man den fejlbesked, at der allerede er bestilt tilflytning på det mpid. Det kan nu godt lade sig gøre. 4.4 Det Frie Marked Versionsmatrix ses på kundeområdet på Angivelse af forsyningsart og rolle på sagerne: Rettelser til de nordiske markeder og Tyskland er angivet i særskilte afsnit. Rolleangivelser angives med følgende forkortelser: Balanceansvarlig Leverandør Netselskab Distributionsselskab : BAL : LEV : NET : NET Desuden angives hvilken forsyningsart rettelsen vedrører: EL : Elkunder GAS : Gaskunder Danmark - SonWin Billing / Engroskomponenter Sagsnummer: RBAL01 RBAL01 går i stå ved Kontrol af Engrostidsserie (EL) (NET/LEV) RMafstem laver, i forbindelse med igangsættelse af afstemningen, tidsserier til kontrol, hvis de mangler. Pga. en fejl, ville den oprette tidsserier til kontrol på kontrol-tidsserier. Disse kontrol af kontrol-tidsserier kan ikke genfindes, og hver gang der igangsættes en afstemning, vil den oprette dem igen. Dermed vokser antallet af tidsserier, der skal behandles i RBAL01, som går i stå af den grund. Rettelse: Fejlen er rettet, således at tidsserierne til kontrol på kontrol-tidsserierne ikke oprettes, og RBAL01 som følge heraf ikke går i stå. Sagsnummer: Marketserver MarketServeren fejler på hent af beskeder i OnHoldQueue (EL) (NET) 17/90

18 Følgende fejl er opstået efter versionen: Fejlen opstår, når markedsserveren skal eksekvere de beskeder, der ligger under det fiktive hovedflow, hvor den får problemer med at finde linjen i OnHoldQueue - der er ingen rækker på det eventtoken, og den melder en fejl i mfejl. Rettelse: Årsagen var, at BRS-017 ikke har svar, og der blev startet et ekstra skeduleringsflow i markedsserveren til udførsel 2 minutter efter afsendelse. BRS-017 er ofte sidste besked i prioriteringsrækkefølgen, og dermed er der intet data at sende efter BRS-017, og ovenstående fejl vil blive logget i MFEJL. Når BRS-017, og alle andre målepunkts-brs'er, er blevet afsendt, så kontrolleres der nu, om der skal afsendes mere. Hvis ikke, så bliver det skedulerede job stoppet. Sagsnummer: mfejl Exception i Mfejl (EL) (LEV) På mfejl kunne man risikere at støde ind i en exception, der lød følgende: "Exception: Subquery returned more than 1 value. This is not permitted when the subquery follows =,!=, <, <=, >, >= or when the subquery is used as an expression." Rettelse: Den kunne opstå, hvis der var flere AMPOP før datoen for opdateringen. Dvs. der lå flere linjer i Sonlinc.Individualmpoints med samme inst+aftagenr med lig eller højere pr.dato end opdateringsdatoen på mmp. Dette er nu rettet. Sagsnummer: mpris Modtagelse af anmodning på prisliste til kontrol fra DataHub (EL) (NET/LEV) Ved modtagelse af prisliste til kontrol (dokumenttype D14) kunne listen ikke vises på fanen Priser til kontrol. Rettelse: Der var tale om et visningsproblem, som er blevet rettet, således at prislisten nu bliver vist efter modtagelsen af en prisliste til kontrol. Sagsnummer: Reorg Reorg kan ikke oprette SWMarket schemaet fra scratch (EL) (NET/LEV) SWMarket reorg kan ikke længere oprette SWMarket schemaet fra scratch, hvilket det burde. Rettelse: Der er lavet koderettelse, således at SWMarket nu kan oprettes fra bunden på en hel tom database, når ikke skemaet findes i forvejen. Sagsnummer: Batsvis Beregnede tidsserier (EL) (NET/LEV) 18/90

19 Det blev oplevet, at beregnede tidsserier ikke længere blev beregnet - hverken igennem baplan eller manuelt i babedato. Rettelse: Årsagen var, at der manglende kvarterer i UTCDATTABEL. Dette skyldes, at rbal01 ikke køres længe nok af gangen, så den når til at danne kvarterne i dens opgaver. Der er derfor lavet en rettelse, så opgaven er lagt tidligere i opgavelisten dermed dannes join tabel (datoer i UTCDATOTABEL) nu i første loop, hvilket forhindrer ovenstående problemstilling i fremtiden. Sagsnummer: Mkonsistens Forventet årsforbrug håndtering (EL) (NET/LEV) Følgende regelsæt for attributten Forventet årsforbrug er nu implementeret i mkonsistens: Knappen Opdater DataHub : - NET: Knappen er aktiv - LEV: Knappen er inaktiv Knappen Opdatering SonWin : - NET: Knappen er aktiv. Når knappen bruges, kaldes speciel metode som også mforslag-skærmbillede kalder, for at få sync et forbruget fra mkonsistens til atlv. Det betyder, at årsforbrug, der accepteres via knappen Opdatering SonWin, lægges ned i SWMarket.NotifyVolumesProposal, og kan ses i mforslag. Der sker herefter en automatisk sync til atlv, når knappen bruges. - LEV: Knappen er aktiv. Når den bruges sync es der automatisk til atlv/ampop (afhængig af målepunktstypen og anlægstypen). Sagsnummer: mkonsistens Fejl i konsistensfiler (EL) (LEV) Der er fundet uhensigtsmæssigheder i masterdatakonsistensfilen. 1. Kolonne E (Netvirksomhed) er udfyldt med et GLN-nr. på aktør, der ikke er Netvirksomhed 2. Kolonne Ay (Elleverandør GLN) er ikke udfyldt. 3. Fejl 1 og 2 har optrådt flere gange i uoverensstemmelsesfilen, og alle de installationer der er slået op, har en slutdato før filen blev dannet i mrolle. Rettelse: Alle punkter er nu løst. Det skyldes, at der ikke blev udsøgt korrekt på, om der er leverance på et målepunkt. Sagsnummer: Mfejl Cannot insert duplicate key row in object (EL) (LEV) Ved følgende fejl i mfejl: Exception: Cannot insert duplicate key row in object 'Sonlinc.ATLVD' with unique index 'ATLVDKEY' er det observeret, at mange af eksemplerne hænger sammen med målerskifte på nettoafregningsgruppe 6, hvor D06 ikke er blevet korrekt opdateret i ampop. Rettelse: Når målerinformation/målerskifte modtages for D06 og D07, vil den indsætte et nyt tælleværk, hvis det ikke findes, og en af udsøgningskriterierne var at EANNR var sat og korrekt. Fejlen ovenfor opstod, når der var et tælleværk, hvor der ikke var sat EANNR. 19/90

20 Til info: D06 er hardcoded til TLVNR 2 og D07 til TLVNR Nordiske markeder + Tyskland - SonWin Billing / Engroskomponenter Sagsnummer: EDI Aperak og control får samme ICR (EL) (LEV) Der var observeret et antal tilfælde, hvor contrl og aperak på modtager edi sendes med samme ICRlognr - med det resultat, at der opstår fejl i modtageren af beskederne. Besked referencer skal være unikke. Rettelse: Metoden til dannelse af ICR lognumre er ændret, så problemet ikke opstår igen. Det nye er, at i stedet for altid at anvende L som første karakter, anvendes nu forbogstavet for beskedtypen som første karakter i ICR lognr Danmark - SonWin Billing GAS Sagsnummer: Batsvis GAS Fejl i visning på BATSVIS (GAS) (NET) Der var et problem med den time, hvor sommertid slutter. På time ser det fint ud, men det fejler i visningen på dag og mdr. i BATSVIS. Rettelse: Det er nu rettet, således at visningen af den sidste time af sommertiden virker på batsvis. Sagsnummer: Alevflow Aflæsningsterminer opdateres ikke korrekt. (GAS) (NET) Ved modtagelse af aflæsningstermin = 31/3 oversætter SonWin det til 1/3, og placerer 2-tallet i aflæsningsterminen på AGAS/AINST i februar måned. Rettelse: Nu fungerer opdatering af aflæsningstermin således: Hvis aflæsningsterminen er sidste dag i måneden, opdateres med 2-tallet i indeværende måned. Hvis aflæsningsterminen er første dag i måneden, skal den opdateres med 2-tallet i foregående måned. Sagsnummer: Atlv Forkert årsagskode ved afs. z01 ved målerudskiftning. (GAS) (NET) Ved test af afsendelse af z01 ved målerudskiftning kode for aflæsning (UDSKF) blev der fundet, at den sender forkert årsagskode. Den vælger periodisk (1), og den skal vælge aperiodisk (3). Rettelse: Nu vælges korrekt årsagskode ved afsendelse af aflæsninger. Også ved målerudskiftninger. 20/90

21 Sagsnummer: RAFR04 Leverandørskift vi modtager udefra på en timekunde (GAS) (NET) Der var et ønske om at få oprettet en SELVAFLAS konvolut også på timekunder ved modtagelse af leverandørskifter. Rettelse: Ovenstående ændring er blevet implementeret. Sagsnummer: REDI01 Udvidet tjek på leveranceforhold ved modt. af stamdata. (GAS) (NET) Der var et behov for at få udvidet tjekket på leveranceforholdet ved modtagelse af stamdata. Rettelse: Nu tjekkes om leverance eller fremtidig leverance haves på både leverancestart datoen og skæringsdato for stamdataændring. Sagsnummer: REDI01 - MSCONS kan ikke afsendes på gasmarkedet (GAS) (NET) MSCONS kan ikke afsendes pga. af rettelse i sag Man får fejlen: "Error: The multi-part identifier "c.datotid" could not be bound.". Rettelse: Nu kan der afsendes tidsseriedata (MSCONS) uden fejl via redi Integration Sagsliste Host SonWin Host er generelt optimeret i denne release. Der skulle nu helst være ca. en faktor 5 på hastigheden mellem der tages fat i processerne. VIGTIGT Reorganisering er flyttet ud af startup og indexes er generelt tilrettet. Derfor kan I forvente, at SonWin Host bruger mellem 5 minutter og 1 time, før den starter op denne gang. Sagsnummer : Retry går ned Det er rettet, således at retry ikke går ned Sagsliste XMLBasis I forbindelse med XMLBasis rettelser er det vigtigt at være opmærksom på sag at der ikke må forefindes databasetriggere længere på BCHEC, AKUNDE og AINSD. Sagsnummer : WEB071a visning af forbrug Web071a er tilrettet, således at perioderne ikke findes på grundlag af regningsdatoer. Det er rettet, så kun første år findes denne vej, resten går altid et år baglæns. Sagsnummer : WEB140 håndtering af tilbagevendere Det er rettet, således at der fremkommer en sigende fejlbesked, når tagget installationsnummer ikke er udfyldt. 21/90

22 Sagsnummer : WEB140 håndtering af tilbagevendere Det er nu rettet, således at web140 ser på mrolle, og validerer mod engrosmarkedsregler ifm. oprettelse af ny forbruger. Dette kun for el. Gas kører videre som nu. Sagsnummer : WEB002b opretning af installation og kunde WEB002b er rettet, således at den altid finder unikke installationsnumre hhv. kundenumre på grundlag af tællere. OBS. Dette betyder, at der ikke må forefindes databasetriggere længere på BCHEC, AKUNDE og AINSD. Sagsnummer : Netselskaber logon samt WEB022 aflæsninger Der er nu korrekt håndtering af aflæsningskuverter ved indlogning. WEB022 er desuden rettet, således at der ikke fremkommer fejl ved mgl. regningsnr på aflæsning for Elnet. Sagsnummer : WEB170 henten af gennemfaktureringspriser WEB170 er nu optimeret, så installationer uden childmålepunkter, som ikke findes i pristabeller i forvejen, hentes inden for 5 sekunder. Er der childmålepunkter, og der ikke forefindes priser i forvejen, er det optimeret, så det tager ca. 10 sekunder oveni pr. childmålepunkt. Kald, hvor målepunkter har priser i forvejen, er allerede hurtige nok. Sagsnummer : Debug-info Debug-info med filnr er rettet, således at korrekt databaseid vises. Eksempel på kald : <debug-info> <filnr>1</filnr> </debug-info> 22/90

23 4.5.3 Andre integrationer Sagsnummer : VisionAir og Synclog Skærmbilledet synclog er tilføjet en ny knap "Synkroniser alle". Ved klik på den nye knap "Synkroniser alle", vil Servicen "SonWin VisionAir integration" tømme sync tabellerne, og efterfølgende vil alle målere automatisk synkroniseres. Det er VisionAir Servicen, som tømmer tabellerne. Dette for at sikre, at det ikke er nødvendigt at stoppe servicen før man trykker på knappen "Synkroniser alle". NB! Når der klikkes på den nye knap, vil der synkroniseres på tværs af alle firmanumre. Vigtigt : Efter installering af den nye version, skal nedenstående script eksekveres på en sql-server. CREATE TABLE Sync.ResetMarker (ResetSync TINYINT); 23/90

24 4.6 Basis Sagsnr Billing server stopper Med udgangspunkt i den dokumentation der er vedlagt sagen, har jeg undersøgt, hvad der går galt. Det viste sig at være en klassisk race condition, der fremprovokerer fejlen. Oprindeligt er funktionaliteten implementeret, således at der ved bestilling af rapporter/jobs i sprn, først hentes seneste ID, og dernæst indsættes data i tabellen. Dette betyder, at der er 2 forespørgsler mod databasen. I visse tilfælde kan det ske, at der hentes samme ID til 2 forskellige jobs. Dette kan læses ud af fejlbeskeden, da indekset ikke vil acceptere 2 enslydende poster. Dermed vil den ene fejle og har desværre den uheldige konsekvens, at det ikke håndteres af Billing Serveren. For at minimere muligheden for at disse fejl opstår, er funktionen ændret således, at hentning af seneste ID foregår på samme tid som indsættelsen af data. Sagsnr sprint bør ignorere tabs fra abemk Bemærkninger fra abemk indeholder ofte karaktere som tabs. Grunden er, at indholdet ofte kopieres direkte fra mails. Dette gør, at sprint låser, når den skal fremvise BEMLISTE fra en printfil, der indeholder tabs. Fejlen er udbedret ved at erstatte tabs med et blankt tegn. Derved opstår der ikke sammentrækninger af ord, der er adskilt af en tab. Sagsnr DB Utility fejler ved Create Logins Vi kan stadig ikke få genoprettet brugere via DB Utility version , så vi kan ikke få vores opdaterede Kursus miljø i luften ift. brugerne - se vedhæftede dok. Der er rettet op funktionaliteten, således at det nu er muligt at oprette brugere uden at angive password. Endvidere er der foretaget en refaktorering af kildekoden, så det ikke længere er nødvendigt at afvikle den som administrator (Run as Administrator), hvilket aldrig har været meningen med applikationen. 24/90

25 Sagsnr Timesag - crasher ved print og PDF Fejlen i relation til dannelsen af PDF er løst. Den ikke-afviklede undtagelse i applikationen, som fejlbeskrivelsen henviser til, dækkede over en uhensigtsmæssig fortolkning af det objekt, der reelt danner PDF en. Sagsnr Microsoft.NET framework fejl i Sprint S Vi får ofte vedhæftede fejl i sprint. Det kan genskabes ved at gøre følgende: Maksimer Sprint og scrol ned med musen (hjulet på musen). Vupti Så er fejlen der. Vi har fejlen både i Citrix og under lokal installation. Implementeringen af at scrolle med hjulet på musen tog ikke højde for, at der ikke kunne scrolles! Med andre ord, der manglende en afskærmning(guard) for at scrolle med hjulet på musen. Sagsnr Nyt felt til angivelse af produktionsfirma Oprettelse af et nyt felt til angivelse af hvilket firmanr, der er produktionsfirma i SWVIRK. Sagsnr Bchec AUTOSAG/KVITTERING har ingen effekt Bchec AUTOSAG/KVITTERING har ingen effekt. Der manglende en implementering af andre modtagere i forbindelse med udsendelse af kvittering for sagsoprettelse. 25/90

26 5 Apendix 5.1 SonWin Host: Opsætning af DTC Distributed Transaction Coordinator DTC skal kun være slået til, hvis Billing databasen ikke ligger på samme database server som Hostens database. Det er vigtigt, at DTC opsættes på begge database servere. Start af DTC servicen. Åben services, find Distributed Transaction Coordinator, højre klik og vælg properties : Distributed Transaction Coordinator skal starte automatisk ved opstart. Dette ændres ved at vælge Automatic i Startup type. Når Startup type er ændret, startes servicen ved at klikke Start, hvorefter servicen skifter Service status til Running. Dette gøres på begge database servere. 26/90

27 Opsætning af DTC service på Billing database serveren Find og åben Component services under administrative tools. Find Local DTC, højre klik og vælg Properties. Ret indstillingerne, så de matcher nedenstående billede. 27/90

28 Opsætning af DTC service på Hostens database server Find og åben Component services under administrative tools. Find Local DTC, højre klik og vælg Properties. Ret indstillingerne, så de matcher nedenstående billede. 28/90

29 Opsætning af firewall for DTC service Disse ændringer skal udføres på begge database servers. Åben Windows Firewall. Klik på Allow an app or feature.. Find og vælg Distributed Transaction Coordinator og tilføj den som tilladt på domænet. Klik OK. 29/90

30 Nu skulle DTC gerne være korrekt sat op imellem de to database servere. For yderligere information omkring DTC opsætning se disse to links: Konfigurering af linked server i SonWin Host For, at hosten kan benytte linket korrekt, skal det konfigureres i SonWin Host Administration. Det er vigtigt at pointere, at SonWin Hosten skal have adgang til at lave direkte adgang til den samme database server, som den også skal kunne nå via link forbindelsen. Som beskrevet ovenfor er link forbindelsen udelukkende nødvendig for at kunne håndtere transaktioner korrekt på tværs at de to databaser. Al adgang til databaserne, som ikke kræver tværgående transaktioner, vil blive udført via en direkte forbindelse. Åbn SonWin Host Administration klienten, og vælg Tools->Settings. For databaser, som skal kunne nås både direkte og via et link fra Host database servere, indsættes linkedname ud over de andre indstillinger. Det linkedname, som skal indsættes her, er det navn, som blev brugt, da linket blev oprettet, altså det navn som ovenfor er angivet som <LINK NAVN>. 30/90

31 Efter at ændringerne er udført, skal SonWin Host genstartes. Dette gøres fra SonWin Host Administration klienten ved at klikke Tools->HOST Service. Tryk Stop og afvendt ændringen i status, herefter tryk Start. Nu vil SonWin Host være i stand til at køre med en Billing database, som ligger på en anden database server. 31/90

32 5.2 Databaseændringer Når der opgraderes fra version til version , vil der blive foretaget følgende databaseændringer i forbindelse med ReOrg (i juli og december vil der ikke blive foretaget databaseændringer): * * Copyright Sonlinc. * No part of this may be used without written permission from Sonlinc. * * * SWAfregn_Rafr40_ > < * ***** Første årsag til reorganisering -> BALOGERROR Felt -> PLANNRType 6 ***** Første årsag til reorganisering -> BATIDSNR Felt -> FAKTORENHType 3 * Tabel -> AFLOWLOCK Index -> AFLOWLOCK_ID1 Felt -> LOCKTOKEN <- medfører Reorganisering. DROP INDEX Sonlinc.AKOND.AKONDKEY_SWIR01 * Tabel -> BALOGERROR Index -> BALOGERRORKEY1 Felt -> PLANNR <- medfører Reorganisering. * Tabel -> SWHostClientScript Index -> ClientScript_ActTime Felt -> ActionTime <- medfører Reorganisering. execute sp_rename [Sonlinc.BALOGERROR],XReorg_BALOGERROR execute sp_rename [Sonlinc.BATIDSNR],XReorg_BATIDSNR DROP INDEX Sonlinc.AFLOWLOCK.AFLOWLOCK_ID1 DROP INDEX Sonlinc.SWHostClientScript.ClientScript_ActTime CREATE TABLE Sonlinc.AFLOWRESPONSIBILITY (FLOWID Decimal(10,0) Not Null default 0,COMPANYID Int Not Null default 0,RESPONSIBLEGROUP Varchar(20) Null,RESPONSIBLEUSER Varchar(20) Null,COMMENT Varchar(8000) Null) CREATE TABLE Sonlinc.AFLOWSEARCH (FLOWID Decimal(10,0) Not Null default 0,INPUTID Decimal(10,0) Not Null default 0,COMPANYID Int Not Null default 0,CUSTID Float Null,CPID Float Null,CPREFID Varchar(1000) Null) ALTER TABLE Sonlinc.AFLOWSEARCH ADD METERPOINTID Varchar(40) Null ALTER TABLE Sonlinc.AFLOWSEARCH ADD MOVEDATE Datetime Null ALTER TABLE Sonlinc.AFLOWSEARCH ADD SUPPLYTYPE Datetime Null CREATE TABLE Sonlinc.BALOGERROR (Id Decimal(10,0) IDENTITY(1,1) Not Null,PLANNR Float Null,LOGNR Float Null,LOGTYPE Varchar(10) Null,FEJLTEKST Varchar(250) Null,FRA Varchar(35) Null,FORSYNART Int Null,EANNR Varchar(40) Null) ALTER TABLE Sonlinc.BALOGERROR ADD MALEPUNKT Varchar(25) Null ALTER TABLE Sonlinc.BALOGERROR ADD TIDSSERIENR Int Null ALTER TABLE Sonlinc.BALOGERROR ADD FIRMANR Int Null ALTER TABLE Sonlinc.BALOGERROR ADD EDBDATO Datetime Null ALTER TABLE Sonlinc.BALOGERROR ADD EDBINIT Varchar(10) Null CREATE TABLE Sonlinc.DunningHistSupply (CompanyId Int Null,ConsumptionpointId Float Null,CustomerId Float Null,ConsumerId Int Null,DebtorId Int Null,SupplyTypeId Int Null,DunningNumber Int Null,DunningBatchId Int Null) ALTER TABLE Sonlinc.DunningHistSupply ADD UserId Varchar(10) Null ALTER TABLE Sonlinc.DunningHistSupply ADD Updated Datetime Null ALTER TABLE Sonlinc.DunningHistSupply ADD Balance Decimal(18,2) Null ALTER TABLE Sonlinc.DunningHistSupply ADD ResponsibleGroup Varchar(30) Null ALTER TABLE Sonlinc.DunningHistSupply ADD CalculatedDeposit Decimal(18,2) Null CREATE TABLE Sonlinc.DunningHistSupplyLog (Id Decimal(10,0) IDENTITY(1,1) Not Null,CompanyId Int Null,ConsumptionpointId Float Null,CustomerId Float Null,ConsumerId Int Null,DebtorId Int Null,SupplyTypeId Int Null) ALTER TABLE Sonlinc.DunningHistSupplyLog ADD DunningNumber Int Null ALTER TABLE Sonlinc.DunningHistSupplyLog ADD DunningBatchId Int Null ALTER TABLE Sonlinc.DunningHistSupplyLog ADD DH Tinyint Null ALTER TABLE Sonlinc.DunningHistSupplyLog ADD AMIRQRefID Int Null ALTER TABLE Sonlinc.DunningHistSupplyLog ADD ActionType Int Null 32/90

33 ALTER TABLE Sonlinc.DunningHistSupplyLog ADD ActionDate Datetime Null ALTER TABLE Sonlinc.DunningHistSupplyLog ADD ActionData Varchar(20) Null ALTER TABLE Sonlinc.DunningHistSupplyLog ADD ActionRecord Varchar(max) Null ALTER TABLE Sonlinc.DunningHistSupplyLog ADD UserId Varchar(10) Null ALTER TABLE Sonlinc.DunningHistSupplyLog ADD ErrorId Int Null ALTER TABLE Sonlinc.DunningHistSupplyLog ADD ErrorMessage Varchar(500) Null ALTER TABLE Sonlinc.DunningHistSupplyLog ADD ErrorDate Datetime Null CREATE TABLE Sonlinc.BATIDSNR ([TimeStamp] timestamp Not Null,MALEPUNKT Varchar(25) Null,TIDSERIENR Int Null,ENHED Varchar(10) Null,TEKST Varchar(150) Null,FAKTORKWH Decimal(11,6) Null,FAKTORENH Decimal(9,4) Null) ALTER TABLE Sonlinc.BATIDSNR ADD MALEFREKVENS Varchar(30) Null ALTER TABLE Sonlinc.BATIDSNR ADD PRODUKTKODE Varchar(25) Null ALTER TABLE Sonlinc.BATIDSNR ADD PRODUKTKODE2 Varchar(25) Null ALTER TABLE Sonlinc.BATIDSNR ADD FRANET Varchar(40) Null ALTER TABLE Sonlinc.BATIDSNR ADD TILNET Varchar(30) Null ALTER TABLE Sonlinc.BATIDSNR ADD ANLAG Varchar(30) Null ALTER TABLE Sonlinc.BATIDSNR ADD EDIELNR Varchar(35) Null ALTER TABLE Sonlinc.BATIDSNR ADD BEMARK1 Varchar(70) Null ALTER TABLE Sonlinc.BATIDSNR ADD EDIELNRPROG Varchar(25) Null ALTER TABLE Sonlinc.BATIDSNR ADD MALEOPERATOR Varchar(20) Null ALTER TABLE Sonlinc.BATIDSNR ADD MALEANSVAR Varchar(20) Null ALTER TABLE Sonlinc.BATIDSNR ADD BEREGNING Varchar(30) Null ALTER TABLE Sonlinc.BATIDSNR ADD MODTAGER Varchar(30) Null ALTER TABLE Sonlinc.BATIDSNR ADD MANUELAFL Varchar(30) Null ALTER TABLE Sonlinc.BATIDSNR ADD FAKTOR Decimal(9,4) Null ALTER TABLE Sonlinc.BATIDSNR ADD PCTGRANSE Decimal(9,4) Null ALTER TABLE Sonlinc.BATIDSNR ADD SUMMERING Varchar(1024) Null ALTER TABLE Sonlinc.BATIDSNR ADD BAGATELGRANSE Float Null ALTER TABLE Sonlinc.BATIDSNR ADD MODTAGER1 Varchar(25) Null ALTER TABLE Sonlinc.BATIDSNR ADD MODTAGER2 Varchar(25) Null ALTER TABLE Sonlinc.BATIDSNR ADD OMDR Decimal(9,4) Null ALTER TABLE Sonlinc.BATIDSNR ADD TARIFSERIE Float Null ALTER TABLE Sonlinc.BATIDSNR ADD TSALIAS Varchar(35) Null ALTER TABLE Sonlinc.BATIDSNR ADD EFFEKT Decimal(12,4) Null ALTER TABLE Sonlinc.BATIDSNR ADD CIFFRE Int Null ALTER TABLE Sonlinc.BATIDSNR ADD SLUTTID Tinyint Null ALTER TABLE Sonlinc.BATIDSNR ADD PRISBOG Int Null ALTER TABLE Sonlinc.BATIDSNR ADD NET Varchar(30) Null ALTER TABLE Sonlinc.BATIDSNR ADD PROGTID Float Null ALTER TABLE Sonlinc.BATIDSNR ADD PROGTYPE Varchar(10) Null ALTER TABLE Sonlinc.BATIDSNR ADD PROGSTART Datetime Null ALTER TABLE Sonlinc.BATIDSNR ADD PROGSLUT Datetime Null ALTER TABLE Sonlinc.BATIDSNR ADD AFREGNART Varchar(10) Null ALTER TABLE Sonlinc.BATIDSNR ADD PRISTYPE Tinyint Null ALTER TABLE Sonlinc.BATIDSNR ADD COMP1 Varchar(35) Null ALTER TABLE Sonlinc.BATIDSNR ADD COMP2 Varchar(35) Null ALTER TABLE Sonlinc.BATIDSNR ADD QTYTYPE Varchar(3) Null ALTER TABLE Sonlinc.BATIDSNR ADD GRADDAGE Int Null ALTER TABLE Sonlinc.BATIDSNR ADD INSTNR Float Null ALTER TABLE Sonlinc.BATIDSNR ADD KONTRAKT Varchar(15) Null ALTER TABLE Sonlinc.BATIDSNR ADD SUMGRUPPE Varchar(20) Null ALTER TABLE Sonlinc.BATIDSNR ADD BALANSVAR Varchar(20) Null ALTER TABLE Sonlinc.BATIDSNR ADD GNSANTALDG Smallint Null ALTER TABLE Sonlinc.BATIDSNR ADD DEVICEID Varchar(50) Null ALTER TABLE Sonlinc.BATIDSNR ADD TRETIDSNR Int Null ALTER TABLE Sonlinc.BATIDSNR ADD STATUS2N Smallint Null ALTER TABLE Sonlinc.BATIDSNR ADD FIRMANR Int Null ALTER TABLE Sonlinc.BATIDSNR ADD EDBINIT Varchar(10) Null ALTER TABLE Sonlinc.BATIDSNR ADD EDBDATO Datetime Null 33/90