Om ReKu
Kukontrollen er grunnlaget for styring, planlegging og kvalitetssikring av mjølkeproduksjonen i Norge. Navet i Kukontrollen er Storfedatabasen. Husdyrkontrollen er avdelingen i TINE som er ansvarlig for Storfedatabasens ve og vel.
Vi i Husdyrkontrollen er i gang med et stort prosjekt, der vi flytter Storfedatabasen fra en teknisk plattform til en annen: Fra et eldre, litt stivbeint teknisk miljø til en mer fleksibel og moderne database. Prosjektet heter ReKu.
Dette påvirker deg som produsent og rådgiver. Du vil etter hvert få en ny Storfedatabase som er mer moderne og fleksibel, og som tilfredsstiller nye krav fra det offentlige.
Før du merker noe til disse forbedringene, må vi jobbe ganske mye på bakrommet med å sette opp ny plattform og lage en ny databasestruktur. Dette arbeidet vil i første omgang ikke vises for deg som bruker – men tro oss – det skjer store endringer i baksystemene.
Vi fokuserer på å legge tilrette for myndighetspålagte krav, som for eksempel krav fra Mattilsynet om ny identifisering av dyr.
Vi vil holde deg orientert om arbeidet i Re-Ku-prosjektet på denne bloggen. Vi tar gjerne i mot dine tilbakemeldinger!
1.
Lars Skramstad 0415071844 | 08.07.10 kl. 08:01
hei ! Supert at det blir en videreutvikling av kukontrollen.
Kunne ønske at struktureringen på menyvalg og bedre design av elementer for å drive bedre og forbedre lønnsomheten.
Eks kalvingsliste, forplan, melkeprognose, fjøsloggen, tabellen som viser levert mengde/ kvalitet og effektivitetskontroll. Dette er hva vi bruker i den daglige drift, den andre informasjonen er vi mindre innom, ikke hvert år.
Lykke til med arbeidet
2.
Ågot Ligaarden | 21.07.10 kl. 09:51
Takk for gode ideer og innspill! Vi gleder oss veldig til å starte på en fornying av websidene når vi har fått ny database og konvertering på plass. Det er helt sikkert riktig som du sier at de funksjonene som brukes mye i den daglige driften bør være lett å finne fram til. Det er viktig med enkelt tilgang til riktig informasjon for å bedre drift og lønnsomhet for dere mjølkeprodusenter.
3.
Heri Andrian | 23.05.11 kl. 12:23
Hei! Har fått endel henvendelse fra produsenter som også har ammekyr i tillegg til melkeproduksjon.
De vil vite om det blir mulig å registrere rase ved paring i framtiden?
Mulighet for å registrere lånt okse fra naboen.
Mvh.
Heri
4.
jørgen skarsvåg | 25.05.11 kl. 19:44
hadde ønsket at ku/individ-nummeret er aktivt uansett hvor ho dukker opp. dvs at vi f.eks kan klikke på nummeret til kua i f.eks kalvingslista og komme direkte til individ-kortet hennes. effektivt
5.
Claude Marie Davidsen | 26.05.11 kl. 09:33
Hei, Jørgen – enig – det tar vi med oss inn i prosjektet!
6.
jørgen skarsvåg | 25.05.11 kl. 19:53
hadde ønsket at en slipper å bruke tid på at registreringer ikke blir tatt til følge. vennligst ordne slik at dere i tine får beskjed når noe ikke går inn eller ikke kommer inn mellom reistrene, slik at vi som registrerer kan føle oss sikre for at det faktisk er registrert. har opplevd div ex: – ved kjøp av kyr i produksjonhar eg fått problemer: får ikke ikke lagt ho inn pga ho sto fortsatt som kvige. og når eg kontakter rådgiveren for å få hjelp, er det eg som må betale for opprettinga. er dette rettferdig?
- eier-insiminerte ei kvige og reg dette på vanlig måte i geno-rapport. men ho kom ikke med på kalvingslista. heldigvis oppdaga eg det, MEN det er ikke dette vi skal bruke tia vår på, eller? når vi har registrert det, må vi få føle oss sikker på at det er kommet med. håper dette for fremtiden. takk.
7.
Claude Marie Davidsen | 26.05.11 kl. 09:41
Hei, Jørgen
Vi lanserte første del av ny database i midten av mars – og en av forbedringene var tilbakemelding til brukerne ved innregistrering.
Når du registrerer noe nå, får du en tilbakemelding om registreringen gikk bra eller ikke. Du får også en nærmere forklaring dersom registreringen ble avvist, slik at du evt. kan prøve på nytt.
Helt enig i at bruker skal føle seg sikker på at registreringene hun/han gjør enten lagres eller at det gis god tilbakemelding.
Diskusjon rundt betaling for rådgivertjenester synes jeg er litt vanskelig å ta her på bloggen – jeg tror det er en sak du må ta direkte med din rådgiver. Det er jo viktig at alle er enige om hva som er fakturerbart arbeid og ikke.
8.
jørgen skarsvåg | 25.05.11 kl. 19:54
er det riktig at jeg skal betale en halv time for at rådgiveren skal bestille ET nytt merke?
9.
Claude Marie Davidsen | 26.05.11 kl. 09:42
Hei igjen – se kommentar over!
10.
jørgen skarsvåg | 25.05.11 kl. 20:06
hva med et søkefelt for individnummer tilgjengelige uansett hvor en her i kukontrollen? bare skrive inn nummeret og komme til individ-kortet, og i kortet ha pekere/rullegardin til alle steder hvor individet er med, slik at en kan gå direkte dit; f.eks kalvingsliste, fjøslogg, veieliste, osv
11.
Claude Marie Davidsen | 26.05.11 kl. 09:43
Hei, dette tar vi også med oss inn i prosjektet – det høres ut som en effektiv måte å få oversikt på. Takk for innspill!
12.
Unni-Lill Dørum | 30.05.11 kl. 11:34
Hei. Fant ut at jeg sender et par kommentarer, i tilfelle det ikke er tenkt på allerede
1) Det hadde vært meget nyttig hvis tabeller på medlemssiden kunne vært overførbart til excel! Hvis jeg prøver å kopiere fra medlemssiden og inn i excel i dag, så oppfatter angivelig ikke excel at det er tall… Så da må jeg i tilfelle sitte og registrere alle tallene på nytt…
2) Jeg skulle gjerne hatt tilgang til 305 dagers avdrått på enkeltdyr, også historiske tall på utmeldte. Og aller helst slik at det var mulig å se avdråtten pr laktasjon på enkeltdyr.
3) EKM på årsutskrift kan med fordel beregnes basert på tørrstoffinnholdet i tankmelka.
Det synes jeg hadde vært bra
!
13.
Claude Marie Davidsen | 31.05.11 kl. 17:30
Hei, Unni-Lill,
– tusen takk for innspill – vi tar også dette med oss videre!
14.
Rikke Filseth | 03.06.11 kl. 11:41
Datavalg i forhold til periodeutskrift og KK-hjul/grafiske framstillinger i TDA:
Periodeutskrift: Så lenge denne blir sendt ut i papirformat, burde ALLE de følgende paramerte være med: ffs, urea og celletall. Med dagens kunnskap om at ffs og urea kan være noe av hverandres forklaringsvariabler, er det noe rart at en i dag kun kan velge en av dem…
Data fra KK: Jeg savner følgende grafikk på bla KK-hjul og KK-grafikk i TDA: bactoscan, ffs og urea.
Håper dette kan vurderes i fremtiden
)
15.
Unni-Lill Dørum | 01.08.11 kl. 08:54
Hei!
Jeg får av og til tilbakemeldinger fra produsenter som ikke får lov i KK til å registrere kalving og så påfølgende melkeveiing. De må først registrere kalving og så vente til neste dag før de får registrert melkemengde. (Selv om det har gått mer enn seks dager etter kalving før melkeveiing.) De får feilmelding om at kalving mangler.
Hva kan dette skyldes? Hva kan evt gjøres for å sikre at det vil fungere for alle i Re-Ku?
Vennlig hilsen Unni-Lill Dørum
16.
Bonde | 04.08.11 kl. 12:29
Hei.
Har opplevd det selv hvis jeg har sendt inn registreringa på kalven. Men dersom jeg ikke sender det inn, men lar kalving ligge “til base” når jeg registrerer melk fungerer det alltid…
17.
Unni-Lill Dørum | 22.08.11 kl. 09:38
Hei Bonde!
Takk for innspill og tilbakemelding. Jeg har snakka med produsenten igjen, og hun forteller at de gjør det slik som deg. Likevel får de problemer…
18.
Claude Marie Davidsen | 22.08.11 kl. 10:33
Hei – prøver meg på et generelt svar. SDB er batch-orientert, dvs. samler opp alle innregistrerte transer og behandler dem på ett tidspunkt (om natten). Da må kalving registreres først, så må behandlingen i systemet gå (om natten) og så kan man registrere melkeveiingen dagen etter.
Når ReKu-prosjektet er ferdig, vil ting fungere på en annen måte. Da vil ikke systemet samle opp transer og så behandle dem samlet på ett tidspunkt, men hver enkelt hendelse vil bli oppdatert i databasen med en gang. Dvs. at man først kan sende inn kalving – pling – som vil oppdateres øyeblikkelig i basen. Så kan man registrere melkemengde – som også oppdateres øyeblikkelig.
Men foreløpig fungerer systemet fortsatt batch-orientert – inntil prosjektet er ferdig.
19.
Unni-Lill Dørum | 22.08.11 kl. 14:46
Hei
Takk for svar.
Jeg får imidlertid ikke dette helt til å stemme… Tidligere da alle rådgivere satt og registrerte veielapper, så brukte i alle fall vi lokalt bestandig å registrere kalvinger og så melk rett etterpå, før vi sendte inn samlet alle registreringene til slutt. Det brukte bestandig å fungere tilfredsstillende. Så vidt jeg vet er det ikke noen endring på det?
Imidlertid er det noen få av produsentene som ikke får dette til å fungere; De må først sende inn kalvinger en dag, og så melk først dagen etter. En av produsentene rapporterer også at hun av og til får feilmelding om at kua er registrert avsint og at dermed blir ikke veiinga godkjent. Og det angivelig selv når ny kalving er registrert.
Hvordan forklarer vi dette til produsentene?
20.
Claude Marie Davidsen | 23.08.11 kl. 14:17
Hei Unni-Lill – jeg sjekker nærmere med fagekspertisen og kommer tilbake!
21.
Claude Marie Davidsen | 24.08.11 kl. 12:30
Hei igjen – nå har jeg vært i dialog med brukerstøtte.
Slike problemstillinger er litt detaljerte å ta på bloggen, så brukerstøtte anbefaler at dersom du opplever dette igjen, så tar du kontakt med brukerstøtte med beskrivelse av den konkrete hendelsen (med spesifikt dyr). Da er det enklere for dem å sjekke hva som skjer.
En mulig forklaring kan være følgende: Når man registrerer kalving og mjølk i registreringsprogrammet, så registrerer man kalvingen først. Man må ikke sende inn data til kukontrollen, men fortsette å registrere inn mjølka. Når både kalving og mjølk er tastet inn, så kan man sende dataene til kukontrollen.
Dersom man taster inn og sender inn kalvingsdata til kukontrollen før man fortsetter å registrere mjølkedata, vil man få feilmelding. Forklaringen her ligger i måten grunnlagsdata hentes ut på til innregistreringsprogrammet.
Jeg vet ikke om det er dette som er årsaken til problemet hos dine produsenter i dette tilfellet, dessverre.
Uansett: Dette vil fungere annerledes når ReKu kommer på lufta – da vil data registreres forløpende i databasen.
Ang. avsiningsproblematikken så anbefaler jeg at du tar kontakt med brukerstøtte når problemet oppstår (med info om konkret dyr/hendelse).
22.
MiaMaria | 22.08.11 kl. 14:42
jeg har en produsent som vil ha framført en ønske om å kunne bestille begere og esker til kukontrollprøvene direkte på nett samtidlig med veieresultatene.
23.
Claude Marie Davidsen | 04.11.11 kl. 13:57
Hei! Takk for forslag!
Snakket nettopp med brukerstøtte. Beger og esker til kukontrollprøvene må bestilles via rådgiver, for denne bestillingen går ikke gjennom vårt system. Hvis man går tom, må man altså sende en e-post til rådgiver.
Når vi er ferdige med nytt innregistreringsprogram, kan det være en mulig løsning å legge på en knapp som automatisk sender en e-post til rådgiver om bestilling av beger. Det kan vi vurdere – og vi legger det inn i Ønsker-og-ideer-listen.
24.
Liv Synnøve Andersen | 02.11.11 kl. 12:34
Det er umulig for produsent å vite ved innkjøp av okser om forrige eier var medlem i KK eller ikke. Hvorfor kan ikke det bare være en type innmelding, og så finner systemet selv ut om forrige eier var medlem i KK?
Lurte og på hvorfor det står med feil skrift “Registrerte data er vellykket innsendt”, også når data er avvist. Endel produsenter leser bare det med feit skrift og får ikke med seg at data kan være feil. Kanskje overskriften kunne være “data avvist” i disse tilfellene.
25.
Claude Marie Davidsen | 02.11.11 kl. 15:22
Hei, takk for innspill!
Jo – akkurat det om medlem/ikke-medlem skal vi prøve å få til i nytt innregistreringsprogram. Systemet (ReKu) vet jo om selger er medlem i KK eller ikke. Derfor bør det ikke være nødvendig for den som registrerer å si noe om det.
Det med registrerte data som er vellykket innsendt, har med batch-kjøringer i databasen å gjøre. Registreringsprogrammet tillater innsending av data (som blir vellykket sendt inn til databasen. Når så batch-kjøringen “kjører” om natten, kan noen data avvises der.
–> Dette er en forbigående problemstilling. Når ReKu-prosjektet er ferdig, vil alle data bli online oppdatert. Dvs. at du får beskjed med en gang om noe er godtatt eller ikke.
26.
Liv Synnøve Andersen | 04.11.11 kl. 12:42
Takk for svar. Når det gjelde melding om “Vellykket innsendt” gjelder det også feilmeldinger som kommer ved innsending, altså ikke avvist “over natten” . Jeg får feks en slik feilmelding ved forsøk på å melde inn som innkjøpt fra medlem i KK, som skulle vært “ikke medlem i KK”. Overskriften som da produsenten ofte får med seg med fet skrift er “Registrerte data er vellykket innsendt”, feilmeldingen tar noen sekunder før de kommmer og her er skriften med “feil” i vanlig skriftstørrelse. Denne er lett¨å overse da vi leser det øverste først.
27.
Claude Marie Davidsen | 04.11.11 kl. 13:07
Hei, igjen, og takk for tilbakemelding. Jeg skal ta det internt, kan være at det er lurt å endre litt på teksten, ja!
28.
Unni-Lill Dørum | 29.11.11 kl. 07:40
Hei. Har fått et til ønske fra produsent: Ved utmelding av dyr bør det være mulig å registrere at et dyr/kadaver er levert til f.eks. Norsk Protein (slippe å føre inn eget produsentnr under “solgt til”).
Støtter også forslaget om mulighet til å huke av ved behov for esker og beger. Får innimellom spørsmål (spesielt fra nye egenregistratorer) om hvor man kan gjøre det i Kukontrollen.
29.
Eirik E | 05.12.11 kl. 10:05
Hei.
jeg har en ide når det gjelder å kombinere KK og KSL som samme innloggings platform. Idag er man ofte inne på KK minst en gang i måneden mens som i mitt tilfelle ofte ikke blir gjort ksl tilbakemelding/kontroller før “purrelappen” kommer i posten.
Ved å ha en egen(f.eks.Rød blinkende) “knapp” på forsiden til KK som fører direkte til Ksl vill en oftere kunne benytte seg av og gjennomføre ksl
f.eks når man setter att avviket skal lukkes innen den og den datoen aktiveres “knappen” hvis avviket ikke er lukket innen fitt dato.
Når vi først ønsker å ha ksl i landbruket bør det gjøres så lettvindt att det faktsik blir brukt, ikke bare fylt ut og glemt.