Podrška #28966
Zatvoren
fakt_fakt->opis koristi li neko ?
100%
Povezani tiketi 2 (0 otvoreno — 2 zatvorenih)
Izmjenjeno od Ernad Husremović prije skoro 14 godina
u verziji 1.3.0 koju pripremam fakt_fakt->dok_veza i fakt_fakt->opis su izbačeni.
Nakon što sam izbacio polje fakt->opis u tabeli pripreme nemam unos opisa ... to treba skroz izbaciti ako niko ne koristi opis.
Ako neko ipak koristi opis NE VRAĆATI polje opis nego dodati tabelu:
fakt_fakt_opis
| idvd | idtipdok | brdok | rbr | opis char(254) |
| 10 | 10 | 000500 | 5 | opis stavke 5 dokumenta 10-10-000500 |
Izmjenjeno od Saša Vranić prije više od 13 godina
dok_veza se također koristi sa radnim nalozima
Izmjenjeno od Ernad Husremović prije više od 13 godina
Saša Vranić je napisao/la:
koristi par firmi ovaj opis
najbolje stavi linkove na funkcije koje koriste ovo polje. Ne znam ni polje uopšte čemu služi
Izmjenjeno od Saša Vranić prije više od 13 godina
u opis upišu nešto što karakteriše samu stavku, možda neke lot brojeve ili slične stvari
Izmjenjeno od Ernad Husremović prije više od 13 godina
otvori na internom projektu za klijente info o tome ko te funkcije koristi na koji način da imamo na umu kod migracije.
kako sam u početku ticketa rekao, to se ne može vraćati u fakt_fakt. ali svakako treba kod migracije paziti na to kod onih koji to koriste
Izmjenjeno od Saša Vranić prije više od 13 godina
postoji tabela fakt_doks2 koja je pretpostavljam bila namjenjena nekada u ovu svrhu, možda je onda bolje nju proširiti pošto je već imamo dostupnu
Izmjenjeno od Ernad Husremović prije više od 13 godina
fakt_dosk2 je planirana kao tabela koja sadrži jednu stavku za jedan dokument
fakt_fakt_opis može da sadrži više stavki dokumenta
Izmjenjeno od Saša Vranić prije više od 13 godina
Dobro, to znam i ja :)
Ali nije opis jedino što je potrebno, imamo i taj broj veze, imamo relaciju, imamo broj radnog naloga i slično
#29469
#28089
#28016
itd...
Izmjenjeno od Ernad Husremović prije više od 13 godina
razlika između br_veze_rnal i fakt_opis potpuna
br_veze_rnal se veže sa fakt_brdok relacijom 0..1 <-> 1 (brveze_rnal može biti 1 ili ne biti 0)
opis se veže sa fakt_fakt zapisom relacijom 0..1 <-> 1 (opis može biti 1 ili ne biti 0)
zato fakt dodatni opis i rnal_brveze polja ne treba smještati u istu tabelu
Izmjenjeno od Saša Vranić prije više od 13 godina
- Prioritet promijenjeno iz Odmah riješiti u Urgentno
Izmjenjeno od Saša Vranić prije više od 13 godina
praktično nama treba tabela koja će sadržati neke dodatne opise i karakteristike po stavkama fakture...
recimo, ovaj tiket je vezan za opis, ali imamo recimo i ona polja:
- serijski broj
- lot broj
- ref broj
- itd...
znam da smo za nekoga pravili i LOT i REF brojeve koji se definišu kod unosa fakture te se po njima može i pretraživati poslije itd...
Izmjenjeno od Saša Vranić prije više od 13 godina
vrlo jednostavno u ovu tabelu možemo dodati i proizvoljna polja, kako je to bilo u FAKT.DBF tabeli:
- c_1
- c_2
- c_3
- c_4
- c_5
itd...
tabela: fakt_opis
| idfirma | idtipdok | brdok | rbr | opis | c_1 | c_2 | c_3 | c_4 | c_5 |
Parametrima setovati šta će predstavljati koje od polja...
- koristi c_1 kao "REF"
- koristi c_2 kao "LOT"
- itd...
po želji...
Na osnovu parametara se onda i na forme kod pretrage može reći, uslov po
- REF, LOT itd...
ili ako nije setovano parametrom (naziv)
- C_1, C_2
to je jedino što mi pada napamet ovdje a da imamo tu mogućnost da možemo definisati ove stvar proizvoljno
Izmjenjeno od Saša Vranić prije više od 13 godina
jedino još ne znam kako uvesti ovu tabelu, da li raditi semafor ili samo napraviti
_fakt_opis.dbf
(pripremnu tabelu)
koja će se puniti i na osnovu koje ćemo puniti server tabelu itd...
Izmjenjeno od Saša Vranić prije više od 13 godina
- Odgovorna osoba promijenjeno iz Saša Vranić u Ernad Husremović
zrakni i ti pa vrati
Izmjenjeno od Ernad Husremović prije više od 13 godina
Saša Vranić je napisao/la:
jedino još ne znam kako uvesti ovu tabelu, da li raditi semafor ili samo napraviti
_fakt_opis.dbf
(pripremnu tabelu)
da li nam temp tabela uopšte treba ? Ove podatke jednostavno možemo držati u memoriji tokom pripreme naloga kao array stavki koje su opet hash array
[
{lot: "lot1", ref: "ref1"}, <<<<<<<<< stavka 1 dokumenta
nil, <<<<<<<<< stavka 2 ne sadrži ove dodatne atribute
{lot: "lot22", ref: "ref22"} <<<<<<<< stavka 3 dokumenta
]
Izmjenjeno od Ernad Husremović prije više od 13 godina
fakt_opis tabela treba izgledati ovako
fakt_opis(idvd, brdok, rbr, atribut, value)
tako recimo stavka 2 dokumenta 10-0050 ima LOT = 122 i REF = R125
=>
fakt_opis(10, 50, 2, "LOT", "122")
fakt_opis(10, 50, 2, "REF", "R125")
Izmjenjeno od Ernad Husremović prije više od 13 godina
nikakvo budalesanje c_1, c_2 nam ne treba
primarni ključ tabele je četvorka (idvd, brdok, rbr, atribut)
Izmjenjeno od Saša Vranić prije više od 13 godina
Ernad Husremović je napisao/la:
nikakvo budalesanje c_1, c_2 nam ne treba
primarni ključ tabele je četvorka (idvd, brdok, rbr, atribut)
da da, to je bolje
Izmjenjeno od Saša Vranić prije više od 13 godina
Ernad Husremović je napisao/la:
Saša Vranić je napisao/la:
jedino još ne znam kako uvesti ovu tabelu, da li raditi semafor ili samo napraviti
_fakt_opis.dbf
(pripremnu tabelu)
da li nam temp tabela uopšte treba ? Ove podatke jednostavno možemo držati u memoriji tokom pripreme naloga kao array stavki koje su opet hash array
[...]
hm... da ali ako izađem iz pripreme ode sve u hendek :) ili izađem iz aplikacije a dokument ostane u pripremi
Izmjenjeno od Ernad Husremović prije više od 13 godina
Saša Vranić je napisao/la:
hm... da ali ako izađem iz pripreme ode sve u hendek :) ili izađem iz aplikacije a dokument ostane u pripremi
možeš poslati na server prije izlaska iz aplikacije ili iz pripreme fakt.
u slučaju brisanja pripreme - pobriši atribute i to je teo.
tabela neka se zove fakt_fakt_atributi
Izmjenjeno od Ernad Husremović prije više od 13 godina
međutim, ako se atributi smještaju na server onda nema smisla da se i ostale stavke ne smjeste na server.
Naime, ima smisla sve podatke u slučaju izlaska iz pripreme prebaciti na server ...
Ali onda dolazimo do potrebe za pripremnim dbf-ovima ... sve to traži malo detaljniju analizu.
zato ima smisla staviti temp dbf tabelu koja će korisniku služiti kao što mu služi fakt_pripr. znači napraviti fakt_pripr_atributi.dbf gdje ćeš ovo moći smjestiti, a da ne ide na server.
Ja sam predložio memoriju da nam bude jednostavnije.
Izmjenjeno od Ernad Husremović prije više od 13 godina
... ali je tu lahkoću teško postići ako se sve u cjelini "ne pretrese" - mislim na koncept svih pripremnih tabela.
Izmjenjeno od Ernad Husremović prije više od 13 godina
- Odgovorna osoba promijenjeno iz Ernad Husremović u Saša Vranić
Izmjenjeno od Saša Vranić prije više od 13 godina
ma ovo je taman prilika da se pretrese i unos fakt dokumenta, to je ostalo dosta zapušteno
Izmjenjeno od Saša Vranić prije više od 13 godina
fakt, atributi:
napravio sam čitanje i upisivanje atributa, napravljene 2 tabele:
- server: fakt_fakt_atributi
- local: fakt_atributi.dbf
Izmjenjeno od Saša Vranić prije više od 13 godina
praktično kod unosa dokumenta imamo:
// iniciramo hb_hash matricu sa mogućim atributima _items_atrib := hb_hash() _items_atrib["fakt_opis"] := get_fakt_atribut( "fakt_opis" ) _items_atrib["lot"] := get_fakt_atribut( "lot_broj" ) // unos stavke fakture edit_fakt_items( .t., @_items_atrib ) // na kraju radimo puširanje podataka iz hash matrice u dbf "fakt_atributi.dbf" fakt_atrib_hash_to_dbf( items_atrib )
Izmjenjeno od Saša Vranić prije više od 13 godina
jedino još ne znam kako da napravim opciju atributa, možda kao listu u parametrima
fakt, dodatni atributi stavke: opis;lot;ref;...
tako da na osnovu toga znamo šta će se prikazati na formi a šta ne...
ili jednostavno napraviti parametre:
- unos opisa stavke (D/N)
- unos REF/LOT broja (D/N)
ma da, to je bolje...
Izmjenjeno od Saša Vranić prije više od 13 godina
ali definitno unos fakture treba razriješiti sa ovim... to je šuma
Izmjenjeno od Saša Vranić prije više od 13 godina
- % završeno promijenjeno iz 0 u 60
Izmjenjeno od Saša Vranić prije više od 13 godina
- Prioritet promijenjeno iz Urgentno u Odmah riješiti
Izmjenjeno od Saša Vranić prije više od 13 godina
hm.... ovdje sada imamo još dilema
recimo, ako ne popunimo polje atributa ono ne bi trebalo ni da se ažurira na server...
međutim, imamo situaciju:
- ažuriramo neki atribut
- naknadna ispravka dokumenta, ukinemo taj atribut (pobrišemo ga), moram ga i na serveru brisati...
Izmjenjeno od Saša Vranić prije više od 13 godina
hendliranje praznih vrijednosti atributa...
znači, ako je vrijednost prazna neće se zapis dodavati na server....
ako smo ipak dodali 3 stavke fakture i imamo 3 atribut/vrijednosti na serveru imamo:
redni broj 1: opis xxxxxxxxxx redni broj 2: opis yyyyyyyyyy redni broj 3: opis zzzzzzzzzz
pa zatim ispravljamo dokument i pobrišemo atribute/vrijednosti za stavke 2 i 3 na serveru ćemo imati:
redni broj 1: opis xxxxxxxxxx
što je ok
Izmjenjeno od Saša Vranić prije više od 13 godina
stvar je što se kod insert-a podataka na server uvijek dešava
- DELETE atributi za dokument 10-10-00301
- INSERT atribut 1 dokumenta 10-10-00301
- INSERT atribut 2 dokumenta 10-10-00301
- INSERT atribut 3 dokumenta 10-10-00301
tako da je onda ovo jako jednostavno
Izmjenjeno od Saša Vranić prije više od 13 godina
jedina stvar koja mi je sumnjiva je promjena broja dokumenta itd... to sada treba vidjeti šta i kako
recimo imam u pripremi dokument 10-10-00500 nakon što sam rekao štampanje i on mi je automatski setovao brojač
- dokumenta
- atributa
ako ručno promjenim broj dokumenta u tabeli na 00501 neću imati dobre atribute.
Izmjenjeno od Ernad Husremović prije više od 13 godina
da li si ti napravio odgovarajuće upgrade procedure - da se podaci iz stare strukture prebace u atribute ?
tako da korisnici koji su ovo koristili ne izgube podatke.
Pretpostavljam da je sličnu stvar potrebno napraviti i kod migracije FMK -> F18 jer je došlo do promjene strukture podataka
Izmjenjeno od Ernad Husremović prije više od 13 godina
nakon migracije treba napraviti opciju da se podaci iz starih struktura pobrišu da ne stvaraju zabunu i zauzimaju prostor bez potrebe.
ovo se može uraditi i "ručno" - odgovarajućim skriptama koje bi te stvari po uspješnom okončanju migracije podataka uradile potreban posao.
ovo svakako treba testirati na podacima korisnika koji su imali podatke koje sada stavljamo u atribute
Izmjenjeno od Ernad Husremović prije više od 13 godina
fakt_doks_atributi¶
analogno atributima vezanim za stavke, najbolje odmah realizovati i atribute vezane za dokument
fakt_doks_atributi
time bi se fakt_doks polja raznorazna c1, c2 vako nako ugasila, takođe bi trebalo sasvim eliminisati fakt_doks2.
U fakt_doks bi se ostavilo samo set najbitnijih često korištenih polja (takva su polja koja su setovana za skoro svaki dokument): fisc_rn i slična polja.
sve ostale podatke premjestiti u atribute
Izmjenjeno od Ernad Husremović prije više od 13 godina
Saša Vranić je napisao/la:
- dokumenta
- atributa
ako ručno promjenim broj dokumenta u tabeli na 00501 neću imati dobre atribute.
ne razumijem. kad je dokument u pripremi podataka nema na serveru. Sve što trebaš uraditi je promjeniti u lokalnom dbf-u atribute.
Da li postoji pripr_fakt_atributi.dbf ili samo fakt_fakt_atributi.dbf ?
Trebalo bi da postoji pripr_fakt_atributi.dbf u kome se nalaze atributi dokumenta u pripremi.
Što se tiče fakt_fakt_atributi.dbf on nije neophodan ako postoje i koriste se funkcije koje podatke za ažurirane dokumente uzimaju isključivo sas servera (što je najčišće - isključujemo potrebu za logikom semafora)
Izmjenjeno od Ernad Husremović prije više od 13 godina
kada malo razmislim fakt_fakt_atributi koji sadrži podatke lokalnih atributa je suvišan.
Treba samo imati pripr_fakt_atributi koji sadrži podatke dokumenta u pripremi.
Tako smo koliko se sjećam na kraju i dogovorili da uradim. Je li tako i urađeno ?
Izmjenjeno od Ernad Husremović prije više od 13 godina
to je bezveze.
Staviti tip text, tako da uopšte neće biti ograničenja na dužinu - broj karaktera atributa.
A što se tiče dbf-a tu pogledati da li postoji sličan tip polja kao što je test.
Izmjenjeno od Ernad Husremović prije više od 13 godina
pregledao sam kod, koliko vidim fakt_fakt_atributi jeste praktično privremena tabela i odnosi se na stavke u pripremi.
Jedino što je zbunjujućeg imena.
bolje je da bude fakt_pripr_atributi.dbf, s obzirom da fakt_pripr.dbf sadrži stavke koje se odnose na te atribute a ne tabela fakt_fakt.dbf koja sadrži ažurirane stavke
Izmjenjeno od Ernad Husremović prije više od 13 godina
upgrade pa briši smeće¶
koliko vidim ovdje je ključna stvar na koju treba dobro riješti kupljenje podataka iz starih struktura, te nakon toga ne ostavljati te beskorisne podatke - pobrisati smeće nakon što se napune atributi
Izmjenjeno od Ernad Husremović prije više od 13 godina
Ernad Husremović je napisao/la:
ovo se sve može riješiti kroz sql migracijske skripte:upgrade pa briši smeće¶
koliko vidim ovdje je ključna stvar na koju treba dobro riješti kupljenje podataka iz starih struktura, te nakon toga ne ostavljati te beskorisne podatke - pobrisati smeće nakon što se napune atributi
- insert into atributi from stare strukture
- delete polja koja nam više ne trebaju
a što se tiče inicijalnih migracija fmk-F18, najbolje je koristiti strukturu < 4.5.2, u nju izvršiti inicijalnu migraciju
a onda pokrenuti upgrade tih baza gdje će posao obaviti migracijske skripte
Izmjenjeno od Ernad Husremović prije više od 13 godina
otvoriti poseban ticket za ovo
Izmjenjeno od Saša Vranić prije više od 13 godina
fakt_fakt_atributi.dbf preimenovani u fakt_pripr_atributi.dbf
Izmjenjeno od Saša Vranić prije više od 13 godina
- Status promijenjeno iz Dodijeljeno u Zatvoreno
- % završeno promijenjeno iz 60 u 100