Sida 1 av 6 FRÅGOR OCH SVAR Sista dag för att ställa frågor är 2013-08-01 Ställ en fråga om den här upphandlingen Fråga gällande skallkravet: "Systemet skall kunna köras via ett webbgränssnitt." Gäller detta krav alla moduler? Exempelvis så finns det inget webbgränssnitt för ekonomisystemet (redovisning, kund-/levreskontra, fakturering, anläggningsregister)utan endast e-handel, utdata/rapporter samt budgetfunktionalitet. Anses kravet uppfyllt med grund i ovan? Punkt 1.46, kravet gäller alla moduler, men kravet avser inte ett fullt grafiskt gränssnitt. Se punkt 2.2 i förfrågningsunderlaget Är det möjligt att kombinera olika prismodeller i upphandlingen? Exv. att e-handelsmodulen har ett SAAS-upplägg (mjukvara som tjänst) och ekonomisystemet har ett licensupplägg (kunder erlägger licens initialt, sedan betalar man en årlig procentuell avgift avseende support och förnyelse) Frågan besvarades 2013-06-19 av Annika Waldemarsson Ja det är möjligt att kombinera olika prismodeller, under förutsättning att alla kostnader är medtagna. När det gäller SAAS upplägg (molnlösning) är detta inte aktuellt. 1.4.2 Pris, Support, vi har vissa klämdagar inte öppet till kl 17 (Skall krav uppfylls ej) Frågan besvarades 2013-06-19 av Annika Waldemarsson Systemsupporten skall ha god tillgänglighet och vara öppen under normal kontorstid. Detta gäller för samtliga punkter där supporten omnämns. Hela leveransgodkännandeprocessen är otydlig. Hur går den till? Hur många dagar har ni på er? Hur hanteras fel?' Vi ser stora risker med dessa otydligheter Tidplan görs upp i samråd med antagen leverantör. Försäkring, det belopp ni efterfrågar på ansvarsförsäkringen överstiger den ansvarsförsäkring vi har tecknat, vi har inte för avsikt att teckna en speciell ansvarsförsäkring för Bromölla kommun. Praxis är 1 mkr Euro. Vi har inte heller en försäkring som täcker indirekt skada, att teckna en sådan försäkring (om det är möjligt) skulle vara väldigt kostnadsdrivande. Försäkringsbeloppet ändras från minst 15 miljoner till 8 miljoner SEK Kontraktshandlingar, vi har svårt att se varför vårt anbud och enbart antagna delar ej tas hänsyn till i prioriteringen. Vilka delar kan ni välja att inte anta? antagna delar utgår. Vitet med tak på 25% är högt och avviker avsevärt från normal praxis
Sida 2 av 6 Förseningsvite kan utgå med högst 25% av samtliga beräknade licens och underhållskostnader avseende aktuellt delsystem, meningen utgår Och ändras till, Vite skall utgå för varje påbörjad sjudagarsperiod som förseningen varar med 1 % av värdet av den del av varan som till följd av förseningen inte kunnat tas i avsett bruk. Dock skall vitet i sin helhet inte överstiga 10 % av sagda värde. Hur ser betalningsplanen ut avseende Licenser Görs upp i samråd med antagen leverantör Anbudsgivarens ansvar är väldigt omfattande och behöver specificeras, t ex vad är en integration och hur går den till mm. Ersättning för driftstörning i Er miljö känns orimlig, även här är det fråga om indirekt skada Se övriga svar I sista stycket under 2.2 Nytt System, anger ni att ni söker en leverantör som kommer att vara er partner under många år samt att leverantören ska utveckla systemet. I kontrast till 1.42 Pris efterfrågar ett fastpris under hela avtalsperioden. Vad menar ni ska ingå i det fasta priset. T ex anger ni att Uppdateringar och releaser som utvecklas för hela marknaden ska ingå. Fastpriset.2.2 står och i motsatts förhållande till 2.4 Införande, där står i stycke 2 att vi ska lämna ett förslag, är detta förslag att se som ett fastprisåtagande? Generella uppdateringar skall ingå i fastpriset Avseende integrationer i 2.5 ser vi i sig inga problem att integrera med omgivande system, men är det er tanke att vi som leverantör ska kontakta era försystemsleverantörer, samt X, ska vi också stå ev kostnader som X tar för att mappa om filer till annat format. Vi har ingen affärsrelation med X. Nej, vi kontaktar själva våra försystemsleverantörer och står för ev kostnader 4.1 Anbudsutvärdering: Med erfarenhet från en stor mängd upphandlingar vet vi att det avseende Bör-Krav, Funktionalitet och Referenser är väldigt jämt mellan oss konkurrenter, att lägga så stor vikt som 40% på pris kommer att göra det svårt för oss att vinna mot befintlig leverantör. Befintlig leverantör har redan klara integrationer, konverteringar krävs ej, samt att man som befintlig leverantör har möjlighet att lämna ett avsevärt mindre omfattande införandeprojekt Ingen förändring Ansvar för fel, samt definition av underhåll och support. Vi tar självklart ansvar för fel, samt utvecklar produkten, men vi kan inte ha kundunika avtal som reglerar hur vi ska utveckla produkten, samt hur vi ska ge support. Vi levererar ett standardsystem med de standardvillkor vi har för nyttjanderätt, underhåll och support. Vår tanke är att vi skall vara med och kunna utveckla och påverka framtida ändringar, dvs vi vill vara en aktiv kund.
Sida 3 av 6 Äganderätt, vi kan aldrig lämna ifrån oss någon äganderätt oavsett om det rör sig om standardsystemet eller kundanpassningar som beställts specifikt av er. Dock äger ni alltid rätt till resultatet av det som anpassningen gör Under punkten Äganderätt sid 9, bilaga 5, systemapplikationer för beställaren, utgår Under Bilaga 5 kommersiella villkor Tvist/Skadestånd. Vi har ingen möjlighet att lämna anbud om skada i detta fall avser indirekt skada, samt om det inte finns ett tak på skadeståndet som står i proportion till upphandlinges värde. Är det möjligt att använda definitioner och avgränsnigar enligt pkt 15.2 och 15.3 i Avtal 90 Allmänna bestämmelser på 35 gånger gällande basbelopp per skadetillfälle samt begränsning av 15% av hela kontraktssumman? Frågan besvarades 2013-06-25 av Annika Waldemarsson Vi återkommer i denna fråga Indirekt skada: Kravet på ersättning för indirekt skada tas bort i sin helhet. Begränsning av skadeståndsansvar: Leverantörens skadeståndsansvar gentemot kunden begränsas till 35 gånger det vid tiden för skadans uppkomst gällande prisbasbeloppet, per skadetillfälle. Såvida inte uppsåt eller grov vårdslöshet föreligger, är skadeståndsansvaret i övrigt begränsat till ett sammanlagt belopp om 15% av hela kontraktssumman. Punkt Ansvar under Bilga 5 kommersiella villkor. Vi kan inte ta ansvar för fel i er interna miljö. Vi det som att leverantören är ansvarig för indirekt skada är det korrekt. Vi förslår att de 2 sista styckena i detta avsnitt stryks. de 2 styckena som börjar med Anbudsgivarens ansvar och slutar med bortfaller utgår. Dock kvarstår meningen "vid driftstörningar på övrig IT-miljö skall Beställaren resp Anbudsgivaren omedelbart meddelas. Ni har i ert förfrågningsunderlag ett antal SKALL-krav. En stor del av dessa rör funktionella krav. Om vi förstår rätt skall dessa funktionella SKALL-krav vara uppfyllda i samband vid en eventuell visning av systemet, i praktiken innebär att de skall vara uppfyllda idag. I ert förfrågningsunderlag står bland annat också under punkten 2.2 Nytt system att ha vårt nya system i många år och därför kommer vi också att lägga vikt vid leverantörens framtidsplaner och utveckling av systemet. Vi förstår då inte ert krav att alla SKALL-krav skall vara uppfyllda idag. Vi kan utlova en plan för att uppfylla dessa krav i närtid, då vi kontinuerligt utvecklar vårt system. Kan ni omformulera era krav gällande tidsaspekten? Frågan besvarades 2013-06-24 av Annika Waldemarsson Skall-kraven skall vara uppfyllda i samband med visningen, men lyft gärna fram vilka skall-krav er fråga berör så kan vi ompröva vart och ett av dessa. Fråga skapad av upphandlare från Kommers. Pris för konvertering av reskontra kan ej inte fastprissättas, eftersom konvertering ej görs normalt. Frågan besvarades 2013-06-25 av Annika Waldemarsson Med ändring av vad som anges i förfrågningsunderlag och bilagor stryks kostnader för konvertering och skall-krav för konvertering av reskontror. Punkt 1.78 i bilaga 2 Kravspecifikation omvandlas till ett bör-krav med 3 poäng. Detta leder till förändringar under 4.2 Utvärderingsbeskrivning i förfrågningsunderlaget.
Sida 4 av 6 Fråga skapad av upphandlare från Kommers. Kontraktshandlingar i avtal/kommersiella villkor Frågan besvarades 2013-06-25 av Annika Waldemarsson Kontraktshandlingar i avtal/kommersiella villkor: Sist i ordningen av kontraktshandlingar görs följande tillägg: Avtal 90, om inget annat uttrycks. Krav 1.48 och 1.106 I några delar av systemet måste man ha flera webbläsare igång för att uppfylla dessa krav. Finns med i vår utvecklingsplan för år 2014. Hur ställer ni er till detta? Krav 4.97 Var vänlig förtydliga. Är kravet att avbetalningsplanen skall kunna exporteras till excel? Krav 10.97 Vi kan leverera denna lösning under år 2014. Hur ställer ni er till detta? Krav 5.24 Det är frivilligt att ange factoring. Uppfylls krav? Krav 4.23 Vi förstår inte helt vad som avses. Om ni menar att inte samma kund kan läggas upp fler gånger kan man dels söka via PG/BG/ORGNR alternativt får man en varning när kund skall sparas. Uppfylls krav? Krav 1.58 I ett fåtal inmatningsformulär etc kan det krävas att mus används för att på ett effektivt sätt kunna jobba i systemet. Vi ser detta som ett modernt sätt att arbeta. Uppfylls krav? Frågan besvarades 2013-06-28 av Annika Waldemarsson Krav 1.48: Kravet uppfylls genom att mer än en webbläsare är öppen. Krav 1.106: Kravet ändras till ett bör-krav med 3 poäng. Krav 4.97: Kravet utgår. Krav 10.97: Kravet ändras till ett bör-krav med 3 poäng. Krav 5.24: Kravet ändras till: i förekommande fall factoring. Krav 4.23: Kravet uppfylls enligt er beskrivning. Krav 1.58: Med registreringsarbete avser vi inmatning av fakturor, bokföringsordrar, uppläggning av kund och leverantör samt dagbokföring. I övrigt kan mus användas vid arbete i systemet. Krav 1.119 Vi löser detta genom det stöd som finns för att flytta ärenden som inte är åtgärdade efter en viss tid. Hur ställer ni er till detta? Krav 4.141 Går att lägga till betalningshändelser. Man får en fråga om man ändå vill betala fakturan fastän saldot är noll. Uppfylls krav? Krav 5.37 Systemet kontrollerar att inga transaktioner har skett på leverantören sedan det datum som anges. Systemet föreslår senaste 12 månaderna. Uppfylls krav? Krav 5.41 Funktion finns att lägga utbetalningarna som fiktiva kunder och generera utbetalningsorder via kundreskontran. Uppfylls krav? Krav 5.46 Sker genom manuellt ange samma referens i referensfältet. Uppfylls krav? Krav 5.72 Ej attesterade fakturor kan makuleras. Har fakturan attesterats av en attestant får en kredit skapas och attesteras och kvittas mot varandra. Uppfylls krav? Frågan besvarades 2013-07-02 av Annika Waldemarsson
Sida 5 av 6 Krav 1.119 Kravet ändras till ett bör-krav med 3 poäng. Krav 4.141 Vänligen precisera frågan. En avskriven faktura i kundreskontran skall gå att spärra så att ingen kreditering sker på densamma. Krav 5.37 Kravet uppfyllt Krav 5.41 Kravet uppfylls troligen inte. Vi söker ett enkelt sätt att hantera enstaka utbetalningar utan att leverantören läggs upp som aktiv i leverantörsreskontran. Att gå via kundreskontran upplevs som komplicerat. Återkom gärna med förtydligande. Krav 5.46 Kravet uppfyllt. Krav 5.72 Kravet ändras till ett bör-krav med 3 poäng. Krav 2.27 Vi ger verifikat ett verifikationsnummer direkt när registreringen påbörjas. Om man ångrar sig/vill makulera är detta fullt möjligt och alla de makuleringar som gjorts kan listas, kan återsökas etc. Allt för att ha en fullständig kontroll över genomförda händelser i samband med avstämningar, revisioner mm. Vid rapportuttag syns makulerad händelse med verifikationsnummer och texten makulerad. Hur ställer ni er till detta? Frågan besvarades 2013-07-02 av Annika Waldemarsson Krav 2.27 Kravet utgår. Krav 10.5 Delfråga godsmottagningsadress Idag saknar vi ett separat fält för denna information Delfråga kodsträngar Kodsträngen kopplas till användaren. Uppfylls krav? Krav 10.15 Leveransadress anges i beställarens användarprofil med godsmottagningsadress saknas idag (se pkt 10.5) Krav 10.17 Det är möjligt att tilldela en användare flera leveransadresser, men ännu inte godsmottagningsadress (se pkt 10.5). Hur ser ni på att vi idag klarar av flera leveransadresser, men ej flera godadresser? Krav 10.91 Det är möjligt att jämföra produkter, men ej genom att markera dem och gå vidare. Uppfylls krav? Krav 10.159 Det är möjligt att ange maxbelopp, dock ej minbelopp. Här har vi faktiskt inte sett något behov. Hur ställer ni er till detta? Frågan besvarades 2013-07-08 av Annika Waldemarsson Krav 10.5 Vi återkommer. Delfråga - godsmottatningadress ändras till bör-krav med 3 poäng. Delfråga - kodsträngar kravet är uppfyllt. Krav 10.15 Vi återkommer. Godsmottagningsadressen utgår. Krav10.17 Vi återkommer. Godsmottagningsadressen utgår.
Sida 6 av 6 Krav 10.91 Kravet är uppfyllt. Krav 10.159 Minvärden tas bort. Vårt förtydligande till Krav 5.41 Vi ser det som en säkerhetslösning och ett sätt att hindra otillbörliga utbetalningar att man lagrar betalningsinformation om någon så får endast en utbetalning. Efter utbetalning kan leverantören/kunden passivmarkeras. De kan också grupperas för att särkskiljas. Två val finns för sådana utbetalningar antingen via leverantörsreskontran eller kundreskontran via automatiska utbetalningar. Engångsleverantör eller engångskund användas och de kan ha egna krav på vilka fält som skall fyllas i. Hur ställer ni er till vårt sätt att uppfylla ert krav? Krav 4.50 Vi förstår frågan och ert syfte, men rent praktiskt är det en svårighet. Det är det mottagande systemet (er kund) som bestämmer hur er faktura visuellt kommer att se ut och vad den kommer att innehålla och vilken information från er den kommer att använda. Tex kan en faktura från er se helt olika ut beroende på era kunders system. Hur ställer ni er till detta? Frågan besvarades 2013-07-08 av Annika Waldemarsson Krav 5.41 Ett ytterligare förtydligande är att leverantören automatiskt efter direktutbetalningen passivsätts. Krav 5.41 ändras till: Det bör finnas möjlighet att skapa enstaka utbetalningar med automatisk passivsättning i leverantörsregistret efter utbetalning. Bör-kravet får 3 poäng. Krav 4.50 Vi vill se en fiktiv fakturabild med den information vi skickat. Denna ska även kunna skrivas ut.