15*Random() ;) "2x50" <2@50.gr> wrote in message news:jm8qn2$odn$1@trimpas.omnitel.net... > Kadangi kainos keiciasi, tai juo labiau reikia issisaugoti realia kaina. > Paprastas scenarijus - ta pati menesi: > - Tarifas paskaiciuoja siuntos X kaina = 10 > - Tarifas paskaiciuoja siuntos Y kaina = 15 > - Kazkas pakeicia siuntos X kaina i 8, tarkim, rankomis > - Pasikecia tarifas siuntai Y, nauja kaina po pakeitimo butu 18 > - Menesio gale kuriama saskaita > > Kokia kaina bus saskaitoj menesio gale siuntoms X ir Y? > > Jau dabar galima teigti (bent jau is tos info kuri yra cia), kad menesio > pabaigoj tikru/sutartu kainu tokioj sistemoj niekas nezino... :) > Man cia panasu i visiskai nereikalinga galvos skausma. Viskas, ka reikia > padaryti, tai prie siuntos saugoti realia kaina jos nustatymo/pakeitimo > metu + visus parametrus, kurie itakojo kaina ar jos pasikeitima (jei > kazkas suteike nuolaida, tai nuolaida irgi turi buti issaugota) tam > atvejui, jei kazkas pradetu gincytis del konkrecios siuntos kainos. > > Kitaip ta ataskaita galima tiesiog randomu generuoti, visvien ji > neteisinga... :) > > "Jornada Del Muerto" wrote in message > news:jm8mlv$k1g$1@trimpas.omnitel.net... > > Na cia esme ta, kad kainos buna keiciasi, ta prasme keisti galima kaip > norima, pvz. kaikuriem klientam jie skaiciuoja nuolaidas, pvz. pagal tai > kiek per menesi siunte ivairios korespondencijos, o kitiems neskaiciuoja, > kitiem galioja pvz nuolaida kazkoks procentas, dar kitiems skiriasi kainos > i butent kazkoki miesta ar kelis. Zodziu per ilga laika pasirasyta > ivairiausiu sutarciu su klientais, su visiskai skirtingomis kainomis ir > susitarimais. Tai sis kainininkas buvo siokia tokia iseitis kaip viska > sukisti i informacine sistema. > > Praktiskai surisimas kainos iraso ir siuntos/laisko butent cia ir > vyksta, sis visas selectas buna kaip View is kurio traukiama > laiskas/siunta + kaina informacija, tiesa buvau buvau sukures ivairiu > lentu ir bandes visaip optimizuoti, kas del kazkokiu duomenu paruosimo, > bet pakolkas taip veikia greiciausia. Esme, kad ivedant/koreguojant > siuntas galima gal butu priskirti kaina, bet gali redaguojamos buti ir > kainos, o tada jau irasu gali buti daug... > > P.S. > > Kas cia gal iseitu padaryti, kad pries pacia saskaitu traukimo > operacija atlikti kazkoki paruosima, vat apie tai kazkiek galvoju, bet > siai dienai tik buvo noras uzklausa jei imanoma pagerinti :) nes kiek esu > isbandes visokiu variantu tai dazniausiai jie tik pablogindavo :) > > > "2x50" <2@50.gr> wrote in message news:jm79kn$nbu$1@trimpas.omnitel.net... >> Tygi paprasta :) >> Visu pirma reiktu sukurta lenta (ar kazkaip pakeisti esamas lentas), kur >> butu fiksuojamos siuntos su realiomis kainomis ir kainas itakojanciais >> faktoriais tada, kai siunta atsiranda realiam pasaulyje (mazdaug - >> klientas, >> miestas, svoris, paskaiciota kaina). Menesio gale paprasta uzklausa su >> grupavimu is tos lentos veiks greitai. >> Juo labiau, kad cia itraukti pinigai ir formuojama saskaita. Generuoti >> saskaita is kainu menesio pabaigoj yra pakankamai rizikinga, nes ansciau >> ar >> veliau bus taip, kad kuriant siunta bus paskaiciuota viena kaina, o >> kuriant >> saskaita bus paskaiciuota kita kaina uz ta pacia siunta. >> Beje, siulyciau pagalvot ir apie tai, ar issiutos saskaitos neturetu buti >> kazkokia forma issaugomos, ypas jei jos gali tureti skirtingus statusus >> pvz. >> issiusta, suderinta, patvirtina, atmesta, koreguota ar pan... >> >> "Jornada Del Muerto" wrote in message >> news:jm3j1l$gu5$1@trimpas.omnitel.net... >> >> Ne cia gale menesio formuojama saskaita faktura, beje klientai gali >> turet ir tukstancius issiustu siuntu/laisku per 1 menesi ar net >> tukstancius >> per diena (pvz. visoki spameriai, kaip bankai ar kokios GSM bendroves), >> tai >> duomenu buna padoriai :) nes paprastai po menesio spausdinama simtam ar >> net >> tukstanciam klientu fakturos, aisku vienu metu po 1, bet tai pvz gali >> daryti >> 10 vadybininku :) na pakolkas kaip ir sukasi, bet uzsakovas turi >> fantazija >> sioje vietoje vis kazka patobulinti, praplesti tuo paciu ir plecia savo >> veikla, kaip sakant sistema tobuleja beveik kiekviena menesi kazkuo :) >> >> Del to vat ir mastau apie optimizacijas :) >> >> "zZz" <zZz@zirzilia.lt> wrote in message >> news:jm27jp$hlq$1@trimpas.omnitel.net... >>> Čia kas? Funkcija? >>> >>> "Jornada Del Muerto" <jornada@lythum.lt> wrote in message >>> news:jm1msp$3lq$1@trimpas.omnitel.net... >>>> Sveiki, >>>> >>>> Turiu tokia situacija su MSSQL 2008, kada reikia istraukti tam tikra >>>> informacija prioriteto tvarka isrenkant viena ar kita irasa is lentos. >>>> >>>> Trumpai aktuali traukimui struktura: >>>> >>>> Siuntos >>>> ---------- >>>> Id >>>> KlientoId >>>> MiestoId >>>> GatvesId >>>> Svoris >>>> >>>> SiuntuKainos >>>> ---------- >>>> Id >>>> KlientoId >>>> MiestoId >>>> SvorisNuo >>>> SvorisIki >>>> >>>> Dilema ta, kad kainu yra 4 tipai (tiksliau nuo siol bus). Egzistuoja >>>> (jeigu id=0 reiskia skirta visiems): >>>> >>>> 1. Bendros/globalios kainos siuntoms (KlientoId = 0, miestoId = 0); >>>> 2. Bendros/globalios kainos konkreciam miestui (KlientoId = 0, miestoId >>>> = >>>> X) - (sis kainos variantas atsiras tik dabar); >>>> 3. Kliento bendros kainos (KlientoId = X, miestoId = 0); >>>> 4. Kliento kainos konkreciam miestui (KlientoId = X, miestoId = X). >>>> >>>> Prioriteto tvarka bandoma priskirti sias kainas: 4, 3, 2, 1. >>>> >>>> Kaip sakant jei klientas turi savo kainas konkreciam miestui tai >>>> jas, >>>> jei tam miestui ner, bet yra aplamai kliento kaina, tada priskiriama >>>> ji, >>>> jeigu nera kliento kainu bet globalios kainos turi kainas tam miestui >>>> tai >>>> si kaina, jeigu nera siam miestui globalios kainos tada bendra kaina. >>>> >>>> >>>> Siuo momentu as darau taip: >>>> >>>> SELECT >>>> kainosId, >>>> CASE >>>> WHEN K4.Id Is Not Null THEN K4.Id >>>> WHEN K3.Id Is Not Null THEN K3.Id >>>> WHEN K2.Id Is Not Null THEN K2.Id >>>> ELSE K1.Id END AS "priceId", >>>> ......... kiti laukai.... >>>> FROM >>>> Siuntos S >>>> LEFT JOIN >>>> SiuntuKainos K1 On K1.KlientasId = 0 And K1.MiestasId = 0 And >>>> S.Svoris >>>> BETWEEN K1.SvorisNuo And K1.SvorisId And ...kitos salygos... >>>> LEFT JOIN >>>> SiuntuKainos K2 On K2.KlientasId = 0 And K2.MiestasId = S.MiestasId >>>> And >>>> S.Svoris BETWEEN K2.SvorisNuo And K2.SvorisId And ...kitos salygos... >>>> LEFT JOIN >>>> SiuntuKainos K3 On K3.KlientasId = S.KlientasId And K3.MiestasId = 0 >>>> And S.Svoris BETWEEN K3.SvorisNuo And K3.SvorisId And ...kitos >>>> salygos... >>>> LEFT JOIN >>>> SiuntuKainos K4 On K4.KlientasId = S.KlientasId And K4.MiestasId = >>>> S.MiestasId And S.Svoris BETWEEN K4.SvorisNuo And K4.SvorisId And >>>> ...kitos >>>> salygos... >>>> >>>> >>>> Tai vat, kokie pasiulymai optimizuoti si shmota? :) >>>> >>>> PS. >>>> Viskas kaip ir veikia, tik dabar reikes dadeti kaina Nr 2 (Globalios >>>> miestu kainos), tai susimasciau gal cia ka eitu pagerinti? >>>> >>> >> >