Pozdrav ,

ja sam Korisniku M5 stavio autorizaciju `Kalkulacija prodajne cijene` u Identima na brisanje, nakon toga nemam nikakvih problema sa dodjelivanjem rabata na narudžbama (ali mogu mijenjati i cijenu).
Baza je od 2 mjeseca 2011, možda se nešto mijenjali u autorizacijama na živoj bazi, pa ti šaljem vtd. datoteku sa autorizacijama kakave su kod mene, probaj ih uvesti na testnu bazu na korinsika M5 i zatim probaj sa tim autorizacijama.
Molim te, meni pošalji trenutne autorizacije od korisnika M5, pa da pokušam zablokirati PA.

U privitku je slika gdje se mogu uvoziti i izvoziti pojedniačne autorizacije.

Pozdrav ,

blokirajne najvjerojatnije nema veze s a autorizacijama, danas smo riješili blokoranje kod otvaranja POS-a, to bi trebalo biti u redu.
Za sve slučajve blokiranja koji se dese ako će ih biti još, molim te, javi mi kada se desi i gdje u programu, spojit ću se na server i pokupiti DatalabError log ili ti pošalji log.

Autorizacije:
Koliko vidim sada korisnici sa trenutim autorizacijama mogu davati rabate na narudžbama i robi.
Ali problemi su:
1) Što u šifarntu idenata mogu mijenjati cijene (zbog autorizacije `Kalkulacija prodajne cijene ` za šifrant identa na brisanje)
2) Što na narudžbama mogu mijenjati cijene.

Ovo i trebalo raditi na sljedeći način:
U Šifrant identa korisnici bi trebali samo moći vidjeti cijene, ne i mijenjati ( autorizacije `Kalkulacija prodajne cijene ` za šifrant identa na čitanje).
Na narudžbama i robi bi korisnici trebali:
1) samo vidjeti cijenu (autorizacija Promjena prodajnih cijena na dokumentu na ništavno).
2) Davati rabate (autorizacija Promjena popusta na brisanje).

Zadnje dvije autorzacije koje se odnose na dokumente trebale bi biti odvojene za narudžbe i dokumente.

Da li je to u redu?

Pozdrav,

Pogledali smo log nadogradnje, izgleda da je neki korisnik radio u bazi za vrijeme nadogradnje tako da se tabele nisu mogle kreirati i zato su logovi puni greške:

ORA-00955: name is already used by an existing object`

I zbog toga dolazi najverojatnije do blokiranja.

Rješenje je ponovna nadogradnja sa svim objektima.

Napraviću to, ali nisam baš uvjeren u točnost tih podataka. Korisnik kaže da niko tu noć nije radio i vjerujem mu jer se to radilo o vremenu između 11 navečer i jedan iza ponoći.
Sljedeće jutro sam nadograđivao drugu bazu na njihovom serveru, niko nije sigurno radio u njoj, a i njezin log je pun ORA-00955 grešaka, i na kraju unatoč tim svim greškama u toj bazi nema problema i zaglavljivanja. Znači da su ponašanja svakakva i vrlo čudna.
I na kraju, zar bi bilo problem napraviti da se nadogradnja ne pokrene ukoliko je neki korisnik logiran u bazi?

U subotu su mi javili samo da su imali jedno zaglavljivanje tog tipa, a jutros su se već javili da niko ništa više ne može raditi.

Znači, ovo smo bili probali zajedno i sve je OK

Pogledam večeras

Pozdrav,

Remark za promjenu cijene na narudžbma - 12853. remark za promjenu popusta na narudžbama 12854, deadline 27.9.
U razvoju su već pristigli zahtjevi da poduzeća mogu mjenjati na dokumentu, a ne u šifrantu idenata i obrnuto, tako da će se i odvojiti autorizacije za prodajnu / nabavnu kalkulaciju.

Sa buildom 5552.07 riješili smo i problem zaglavljivanja, ali ostavit ćemo ticket još otvoren ovaj tjedan za svaki slučaj, da vidimo kako će se program ponašati.

Ovdje se u remarku spominje samo `autorizacija na cene`, pa ako je do sada postojalo u robi autorizacija na mijenjanje cijene i posebno rabata, onda bi se sada to prema remarku trebalo preslikati i na narudžbe.
Odvojena autorizacija na cijene je jako bitna jer veliki broj prodavača ne smije mijenjati cijene, a ima dozvoljen okvir rabata u kojem se može kretata i to se može kontrolirati. Ako ima i mogučnost da mijenja cijene onda je to puno teže kontrolirati.
Inače, ja ne vidim potrebe u praksi za tim odvojenim autorizacijama na modulima roba i narudžbe jer generalno ako mogu davati rabate i/ili mijenjati cijene, onda je sasvim normalno u praksi da to mogu na oba modula.
Ovaj remarkje nastao, koliko se meni čini, zato jer smo sada dobili situaciju da korisnik ima pravo davati rabate na računima, a nema na ponudama ukoliko mu nedamo u šifrantu idenata pravo na mijenjanje prodajne cijene. I po meni rješavanje problema ide krivim tokom.
Sada čemo dobiti prodavača koji će moči mijenjati cijene i davati rabat na ponudama, a npr. ne na računima, i šta če se desiti ako ponudu prebaci na račun. Unatoč tome što nema autorizaciju na mijenjanje cijene dobiti čemo rezultat da je cijenu promjenio.
Po meni je autorizacija na prodajnu kalkulaciju ista stvar neovisno da li ju gledamo u dokumentu nabave, prodaje ili šifrantu. I isto tako pravo na mijenjanje prodajne cijene nema veze sa prodajnom kalkulaciom već bio onaj ko to pravo ima trebao moći mijenjati cijene na svim dokumentima.
Ovo dijeljenje po modulima bi moglo dovesti i do toga dasada neko traži dijeljenje i po VD-u, npr. da prodavač može u 300 mijenjati cijene, a na POS-u ne, nastaje užas ikomplikacije.
Da probam rezimirati, mislim da bi autorizacije na rabate i promjenu cijene trebale biti na jednom mjestu i da se odnose na sve dokumente gdje se takve mogučnosti pojavljuju. Isto tako i za kalkulacije nabave i prodaje, čemu nekom to zabraniti na dokumentu, a dozvoliti u šifrantu (ili obrnuto), opet imamo apsurdnu situaciju da če se promjenjeno prenestiili sa dokumeta u šifrant ili obrnuto.
A partneri moraju 3 puta više klikati kod postavljanja, što košta a niko neče da plati i normalno, mogučnost greške se povečava.