Pokušavam da citiram chips-ov post, ali nešto neće. U svakom slučaju ovo se odnosi na njega, a i na ostale zainteresovane.
Možda je šifra 1000017 cenovnikom od 21.01.2009 promenila cenu (mrzi me sad da tražim) ali važenje nove cene je od 19.01.2009. I ne samo ova šifra, skoro sve šifre su taj dan promenile cenu. Znači, sve što ti je uneto do 19.01. ima staru cenu, u ovom slučaju 217,00. Sve od 19. ima cenu 167,00.
Ne treba da gledaš datum objave cenovnika već polja Vazi_od i Vazi_do u tabeli UslugaRZZO u bazi.
Znači, ne slažem se sa tobom da je datum promene cene 21.01.
Ne bih komentarisao HEAT i to kako on radi, ali evo nekih mojih zapažanja. Ne kažem da su tačna, ali što bi Balašević rekao "Možda grešim, ali ja sam takvog dojma"
HEAT, prilikom unosa podataka, koristi cene iz tabele "UslugaCena", koja se puni pomenutom opcijom "Primeni RZZO cenu". Da ne upotrebim težu reč, mana te opcije je što ona tom prilikom postavlja datum pokretanja opcije a ne onaj datum koji piše u tabeli UslugaRZZO, odnosno ono što je stiglo u XML fajlu u tabeli UslugaRZZO. To sa datumom pokretanja je zaista van pameti.
Da, u pravu si, cena biva zakucana u trenutku unosa podataka i ostaje nepromenjena ako naknadno ažuriaš šifrarnike. To se odnosi i na kreiranje fakture. Šta si ukucao, ukucao si. Sa malo egzibicije u SQL-u moći ćeš to da izmenjaš. Zato sam u svom programu i pravio kontrole koje retroaktivno menjaju unete cene u skladu sa promenamam u šifrarnicima.
Zaključak drugi? Tačno! HEAT nema pojma kada se desila promena cene, mada to piše u šifrarnicima.
Zaključak treći. Ko koristi HEAT nema vremena da sedi kući i drži noge u lavoru, već mora da čupi na portalu i čeka nove cene kako bi ih odmah implementirao.
Ja sam okačio irišku primarnu i nisu imali primedbe. Držao sam se ovih pravila koje sam ti naveo gore.
Jedino me muče sa tim prevozom pa ću sačekati sutra da vidim da li su ga ispravili.
E da, naravno ne koristim HEAT. Imam bolji program.
pozz.
[Ovu poruku je menjao levovnik dana 10.02.2009. u 07:42 GMT+1]