Podrška #29724
Zatvoren
FAKT fakturisanje po objektima
Dodano od Ernad Husremović prije više od 13 godina. Izmjenjeno prije više od 13 godina.
70%
Povezani tiketi 2 (0 otvoreno — 2 zatvorenih)
Izmjenjeno od Ernad Husremović prije više od 13 godina
objasni kako se to sada koristi sa FMK, opiši, referenciraj se na releventne dijelove FMK koda
Izmjenjeno od Ernad Husremović prije više od 13 godina
isto kao i za rnal, napravi video od par minuta
Izmjenjeno od Saša Vranić prije više od 13 godina
znači postoji šifrarnik radnih naloga (id, naz) u koje unose šifru i naziv objekta na kojem rade, recimo
- 1001 - importane sarajevo
- 1002 - centar 22 maglaj
- 1003 - merkator centar sarajevo
itd...
prilikom unosa izlaza u FAKT-u referenciraju se na objekat, pa kažu, otpremnica i kažu RNAL = 1002 i to se sve upiše u DOKS.
referenciram se na fmk kod, jer je u F18 dosta toga izbačeno, recimo RNAL šifrarnik ne postoji
Evo taj dio unosa unutar fakt-a, znači čista referenca na šifranik RNAL.
https://github.com/bringout-fmk/fakt/blob/master/dok/1g/knjiz.prg#L1378
Evo kreiranja tabele šifranika:
https://github.com/bringout-fmk/fmk_common/blob/master/svi/db.prg#L345
i standardna funkcija P_RNAL
https://github.com/bringout-fmk/fmk_common/blob/master/svi/rnal.prg#L17
Pošto ovo radi Hano, izlaz se pravi prema Rama-glas-u recimo i povezuje se sa objektom/radnim nalogom iz ovog šifranika.
Nakon toga se kod prenosa FAKT->KALK ta veza prenosi sve do finansija putem KALK->FIN.
Izmjenjeno od Saša Vranić prije više od 13 godina
na FAKT/kartica izvještaju postoji uslov po radnom nalogu, tako da se može dobiti praktično sva roba isporučena za pojedini radni nalog
Izmjenjeno od Saša Vranić prije više od 13 godina
ova funkcionalnost je najbitnija magacioneru jer to njemu služi da zna šta je isporučeno prema objektu itd...
Izmjenjeno od Saša Vranić prije više od 13 godina
to je znači "objekat isporuke" ali je neko stavio RNAL, ne znam zašto, vjerovatno kao svaki objekat građevinski je jedan radni nalog - tom logikom vođeno
Izmjenjeno od Ernad Husremović prije više od 13 godina
očeivao sam da ćeš prvo završavati čagu ?
Izmjenjeno od Saša Vranić prije više od 13 godina
upravo uzimam to za čagu, nego ovo mi je friško pa samo da ispišem
Izmjenjeno od Ernad Husremović prije više od 13 godina
postavlja se logično pitanje, koja je razlika između fakturisanja hano i ramaglas u ovom kontekstu ?
i ramaglasu su bitni radni nalozi, odnosno kojem se objektu fakturiše.
zar ovo sve nije jedna te ista stvar, s tim što ta praćenja rama-glas radi detaljnije od hano-a (koristi RNAL)
Izmjenjeno od Ernad Husremović prije više od 13 godina
da li se brzo može vratiti u funkciju ovo u F18 pri čemu bi se u obje organizacije (RG i HANO) koristio jedan jedinstveni uslov:
if rnal()
. ....
endif
pri čemu hano kao i do sada ne bi radio ništa sa rnal-om
ili je potreban poseban feature "fakturisanje, isporuka robe po objektima", neovistan o RNAL funkcijama ?
Izmjenjeno od Ernad Husremović prije više od 13 godina
Pošto ovo radi Hano, izlaz se pravi prema Rama-glas-u recimo i povezuje se sa objektom/radnim nalogom iz ovog šifranika.
Nakon toga se kod prenosa FAKT->KALK ta veza prenosi sve do finansija putem KALK->FIN.
Sve pričaš o FMK bazi podataka hano ?
Da slučajno HANO i RG baze podataka u FMK nemaju neke dijeljene podatke ?
To u F18 nije moguće
Izmjenjeno od Saša Vranić prije više od 13 godina
Ernad Husremović je napisao/la:
da li se brzo može vratiti u funkciju ovo u F18 pri čemu bi se u obje organizacije (RG i HANO) koristio jedan jedinstveni uslov:
if rnal()
. ....
endifpri čemu hano kao i do sada ne bi radio ništa sa rnal-om
ili je potreban poseban feature "fakturisanje, isporuka robe po objektima", neovistan o RNAL funkcijama ?
Praktično je to neovisna opcija...
Izmjenjeno od Saša Vranić prije više od 13 godina
ovdje je najlakše znači napraviti isto što je i bilo, samo što bih ja ovu tabelu preimenovao u tabelu
- fakt_objekti.dbf
I stavio je na server pod semafore itd... klasični šifrarnik i postavio kako je i bilo.
To je svakako jedna funkcionalnost koja se može koristiti i za neke druge potrebe gdje treba neka selekcija itd...
Izmjenjeno od Ernad Husremović prije više od 13 godina
Saša Vranić je napisao/la:
ovdje je najlakše znači napraviti isto što je i bilo, samo što bih ja ovu tabelu preimenovao u tabelu
- fakt_objekti.dbf
I stavio je na server pod semafore itd... klasični šifrarnik i postavio kako je i bilo.
To je svakako jedna funkcionalnost koja se može koristiti i za neke druge potrebe gdje treba neka selekcija itd...
napravi tako
Izmjenjeno od Saša Vranić prije više od 13 godina
Jedino ostaje pitanje gdje pohraniti podatak o samom objektu na nivou dokumenta, u fakt_atribute kroz prvu stavku dokumenta ?
Izmjenjeno od Saša Vranić prije više od 13 godina
prije je to bilo polje fakt_doks->idradnal
Izmjenjeno od Ernad Husremović prije više od 13 godina
sve trpaj u txt
međutim ovaj kod nije dobar:
if _len >= 17
d2n2 := _memo[17]
endif
if _params["destinacije"] .and. _len >= 18
_destinacija := PADR( ALLTRIM( _memo[18] ), 500 )
endif
if _params["fakt_dok_veze"] .and. _len >= 19
_dokument_veza := PADR( ALLTRIM( _memo[19] ), 500 )
endif
Izmjenjeno od Ernad Husremović prije više od 13 godina
treba inicijalizirati varijable u svakom slučaju
if _len >= 17
d2n2 := _memo[17]
endif
if _params["destinacije"] .and. _len >= 18
_destinacija := PADR( ALLTRIM( _memo[18] ), 500 )
else
_destinacija := ""
endif
if _params["fakt_dok_veze"] .and. _len >= 19
_dokument_veza := PADR( ALLTRIM( _memo[19] ), 500 )
else
_dokument_veza := ""
endif
pardon ... Ipak vjerovatno to neće praviti probleme, jer se radi o čitanju.
Međutim kod zapisivanja parametara treba uvijek upisati sve parametre, bez obzira da li se koriste ili ne.
Zašto ?
Zato što će ako je npr. destinacije=off, a fakt_dok_veze=on to izazvati zbrku, pa će se čitati pogrešni parametri
zato je najbolje da uvijek upisuje txt koji sadrži u sebi 19, odnosno 20 varijabli
Izmjenjeno od Ernad Husremović prije više od 13 godina
znači
- konkretno dodati idradnal u txt kao _memo [ 20 ]
- uvijek u txt polje, prva stavka upisati sadržaj tih 20 parametara
Izmjenjeno od Ernad Husremović prije više od 13 godina
Međutim kod zapisivanja parametara treba uvijek upisati sve parametre, bez obzira da li se koriste ili ne.
provjerio sam to tako i radi već sada:
https://github.com/knowhow/F18_knowhow/blob/master/fakt/fakt_unos_dokumenta.prg#L771
što znači da će len od matrice _memo uvijek biti maksimalan (20)
Izmjenjeno od Ernad Husremović prije više od 13 godina
"fakt_objekti" funkcija¶
Pošto je ovo neovisna, a odnosi se na mogućnost fakturisanja po objektima. Otvori parametar "fakt_objekti"
znači
if _params["fakt_objekti"]
_idradnal := VAL( _memo[20] )
else
_idradnal := 0
endif
Izmjenjeno od Saša Vranić prije više od 13 godina
Da, tako i napravljeno, obezbjedio sam parametar i unos obeketa na unosu dokumenta i njegovo ažuriranje u fakt_fakt->txt polje.
Sada postoji dio ispisa toga na samom dokumentu, također postoje uslovi na izvještajima
- kartica
- pregled dokumenata
- itd...
gdje se može zadati taj objekat
To sada treba također implementirati. To je sada malo teže jer je u opisnom polju u matrici, dok je prije to bilo polje unutar tabele fakt_doks pa je lako bilo napraviti filter.
Sada filter treba da radi i drugu funkciju, a to je provjera da li je je objekat sastavni dio ove matrice txt
Izmjenjeno od Ernad Husremović prije više od 13 godina
ne razumijem u čemu je problem zar se funkcija ne može koristiti u filteru
function fakt_idrnal(cVal) PushWa() if cVal == NIL pročitaj radni nalog else setuj radni nalog u matric endif PopWa() return pročitani idradnal
Izmjenjeno od Ernad Husremović prije više od 13 godina
funkcija je po novom imenovanju fakt_objekat_id()
a što se tiče setovanja to se može ispustiti sada pošto se to odrađuje za sva ta dodatno polja odjednom.
Izmjenjeno od Ernad Husremović prije više od 13 godina
- Naslov promijenjeno iz FAKT Hano, fakturisanje po objektima u FAKT fakturisanje po objektima
Izmjenjeno od Ernad Husremović prije više od 13 godina
- Projekat promijenjeno iz 103 u F18
Izmjenjeno od Saša Vranić prije više od 13 godina
Izmjenjeno od Saša Vranić prije više od 13 godina
- % završeno promijenjeno iz 0 u 70
Izmjenjeno od Saša Vranić prije više od 13 godina
ostalo jedino da se napravi skripta koja će napraviti kopiranje ovih podataka iz fakt_doks->idradnal u txt memo polje za sve dokumente
Izmjenjeno od Ernad Husremović prije više od 13 godina
to je aktuelno samo za jednog korisnika, tako da ne treba ići kroz automatski upgrade.
najlakš u F18 opciju koju ćemo nakon upotrebe izbrisati
Izmjenjeno od Ernad Husremović prije više od 13 godina
najbolje napravi to odmah dok si "vruć" sa opcijom
Izmjenjeno od Saša Vranić prije više od 13 godina
hm... jedino što postoji jedan problem, a to je da u f18 bazi sada uopšte kod upload-a dbf-a nemamo polje "idradnal" jer ga nema u bazi na serveru pa se to polje preskoči
Izmjenjeno od Saša Vranić prije više od 13 godina
2 opcije:
1) uvesti polje idradnal na server - iskoristiti za update, pa ga nakon svega što se završi pobrisati itd...
2) napraviti opciju koja će provrtiti zadati dbf fajl sa diska na računaru i napraviti upload podataka na server
Izmjenjeno od Ernad Husremović prije više od 13 godina
Saša Vranić je napisao/la:
2 opcije:
1) uvesti polje idradnal na server - iskoristiti za update, pa ga nakon svega što se završi pobrisati itd...
2) napraviti opciju koja će provrtiti zadati dbf fajl sa diska na računaru i napraviti upload podataka na server
nema dileme. trebamo to kod jednog korisnik. uraditi ručno alter add colum prilikom migracije i to je to.
Izmjenjeno od Saša Vranić prije više od 13 godina
da, ali treba i na dbf strani, radi semafora, između ostalog lokalni dbf se gleda
Izmjenjeno od Saša Vranić prije više od 13 godina
E sada jedino napraviti da se napravi sql query na sql strani...
Znači, napravimo alter i dodamo prije migracije polje na server strani
Napravimo migraciju... imamo polje
Opcija konverzije treba onda da uradi:
- sql upit sa servera gdje god postoji puno polje "idradnal" te se za te dokumente prođe i setuju se baze
Izmjenjeno od Saša Vranić prije više od 13 godina
Time se ne remeti lokalni fakt_doks dbf niti se mora paziti na semafore
Izmjenjeno od Ernad Husremović prije više od 13 godina
vratimo se unazad
uzmi za potrebe migracije verzju u kojoj su ta polja bila.
ona će kreirati dbf-ove, slično uzmi serversku bazu te verzije
nakon svega izvršiti upgrade.
Izmjenjeno od Ernad Husremović prije više od 13 godina
samo navedi verziju baze i verziju F18 koji se treba koristiti za migraciju
testiraj i ovo je sve spremno
Izmjenjeno od Saša Vranić prije više od 13 godina
to nije nikada portirano na f18 bazu od samog početka
Izmjenjeno od Saša Vranić prije više od 13 godina
jer to polje nije bilo niti u inicijalnoj verziji dbf-a nego je bila posebna modifikacija struktura kojom se to dobivalo
Izmjenjeno od Saša Vranić prije više od 13 godina
masu polja sam ja naknadno uvodio iz tih modifikacija kada smo uvodili f18 bazu, nakon prve inicijalne
Izmjenjeno od Saša Vranić prije više od 13 godina
ma mislim da je opcija 2 koju sam predložio najpogodnija, samo učitati kao temp tabelu lokalni dbf sa lokacije i provrtiti... time nećemo ništa narušavati niti imati potrebe dodavati polja na serveru itd...
Izmjenjeno od Ernad Husremović prije više od 13 godina
vratimo se unazad sa source-om¶
recimo da je F18 1.1.30 verzija koja sadrži sva ona silna stara polja koja imamo
git checkcout 1.1.30 git branch migriraj_legacy napravi upgrade - dodaj to polje
recimo da je server db 4.2.5
git checkout 4.2.5 git branch migriraj_legacy napravi upgrade - dodaj što treba
u konačnici ćemo imati branch "migriraj_legacy" za ove svrhe
Izmjenjeno od Ernad Husremović prije više od 13 godina
ovo je bolje ta stara polja još mogu zatrebati. u ovaj branch ćemo moći dodati ako se još nešto pojavi.
Što se tiče numeracije, pod pretpostavkom da su verzije kao gore dodati u najmanji broj +50, da nema konfliktima sa verzijama koje su izašle nakon toga
F18 1.3.30 => 1.3.80
server_db 4.2.5 => 4.2.55
Izmjenjeno od Saša Vranić prije više od 13 godina
jeste, ali to znači da je to prvi korak koji se mora napraviti kod nove baze
prvo na tu verziju, pa napraviti i završiti sve, pa onda upgrade na zadnju verziju baze
ali ako slučajno otkrijemo neko novo polje, to više nećemo moći korsititi na novoj bazi
Izmjenjeno od Ernad Husremović prije više od 13 godina
"fmk_migration" branch¶
Ispravka, nek se branch zove fmk_migration
ovaj branch nam definitivno treba. trebali smo ga odmah napraviti, s obzirom da se nakon njega pojavljuje razlika u strukturi tabela FMK <-> F18
Izmjenjeno od Ernad Husremović prije više od 13 godina
Saša Vranić je napisao/la:
jeste, ali to znači da je to prvi korak koji se mora napraviti kod nove baze
prvo na tu verziju, pa napraviti i završiti sve, pa onda upgrade na zadnju verziju baze
ali ako slučajno otkrijemo neko novo polje, to više nećemo moći korsititi na novoj bazi
Mogli bi u beskonačno ići na "ako ...."
Na ovo moraš paziti kod 1% korisnika. Kod 99% ne moraš. Oni nisu ni koristili ova polja
Ovo je dobro i brzo rješenje. Zbog ovakvih stvari i koristimo git. Iskorisitmo ga.
Izmjenjeno od Ernad Husremović prije više od 13 godina
a što se tiče ručnog dodavanja polja u dbf, ako zatreba na terenu.
F18_modstru_dbf se može napraviti ako zatreba veoma brzo.
znači nešto što bi odradilo
F18_modstru_dbf priozvoljni.chs # ako ne navedeš nikakav argument neka traži 'f18_custom.chs'
slično kako je urađen F18_test (dodati F18_modstru.hbp)
Izmjenjeno od Ernad Husremović prije više od 13 godina
F18_migrate_dbf¶
ili da se ovo odmah uradi ?
tako da se za potrebe migracije napravi f18_fmk.chs, kao i f18_fmk.sql za serversku stranu i to je to ...
Ovo je takođe dobro rješenje
Koje god odabaremo nećemo pogriješiti.
Izmjenjeno od Ernad Husremović prije više od 13 godina
ovo F18_migrate_dbf svakako je serviseru može biti dobar pomoćni alat. napravi ovako
Izmjenjeno od Saša Vranić prije više od 13 godina
da, to je pametnije, možeš odraditi modifikaciju, odraditi neku konverziju posao, zatim odraditi kontra modifikaciju da se vrati na prvobitno stanje
Izmjenjeno od Saša Vranić prije više od 13 godina
konkretno u našem slučaju bi bilo
- postavim praznu tekuću bazu
- napravimo modifikaciju sa utilitijem
- migriramo podatke
- uđemo u aplikaciju i odradimo konverziju
- napravimo kontra modifikaciju koja će ukinuti nova/stara polja
Izmjenjeno od Saša Vranić prije više od 13 godina
ali :)
naravno, opet isti slučaj, to je kod init baze, ako se uoči nešto naknadno, ovo nam ne može više ovako korsititi jer već imamo formiranu bazu
Izmjenjeno od Saša Vranić prije više od 13 godina
ja sam recimo svojevremeno kod migracije TOPS podataka imao sličan problem
- šifre POS su bile različite od šifara FMK modula
- ili su se koristile samo artikli iz šifranika POS
- mi smo u F18 šifrarnik artikala objedinili i POS i ostali moduli koriste identičan šifrarnik
- međutim, kod migracije je problem jer POS/roba ima drugačiju strukturu
- ja sam u tu svrhu radio običnu opciju migracija POS/roba -> F18/roba gdje se čita lokalni dbf sa neke lokacije
Izmjenjeno od Ernad Husremović prije više od 13 godina
fmk_migrate nam takođe treba¶
Kako vrijeme ide, razlike FMK strukture podataka i F18 će logično biti sve veće. A biće potrebe da se korisnici migriraju i nakon pola godine ili godinu
Zato je 'fmk_migration' branch potreba.
Ako se recimo ne migrira do kraja godine, trebaćemo se vratiti unazad i radi ovoga http://redmine.bring.out.ba/issues/29766#note-18
Izmjenjeno od Ernad Husremović prije više od 13 godina
Saša Vranić je napisao/la:
ja sam recimo svojevremeno kod migracije TOPS podataka imao sličan problem
- šifre POS su bile različite od šifara FMK modula
- ili su se koristile samo artikli iz šifranika POS
- mi smo u F18 šifrarnik artikala objedinili i POS i ostali moduli koriste identičan šifrarnik
- međutim, kod migracije je problem jer POS/roba ima drugačiju strukturu
- ja sam u tu svrhu radio običnu opciju migracija POS/roba -> F18/roba gdje se čita lokalni dbf sa neke lokacije
U 'fmk_migrate' branchu možeš sve ove stvari bez posebnog razmišljanja realizovati.
znači možeš napraviti pos_roba tabelu i u nju smjestiti što treba, pa onda merdžirati na sql konzoli.
Znači možeš dodavati na stranu servera tabele, na stranu dbf-a kako ti paše radi migracije, da bi se ovakve situacije olakšale.
Kada se sve izmigrira kako treba onda se sve može izbrisati. sa drop table na strani servera a na strani klijenta nova verzija će kreirati strukture kako po novom.
Izmjenjeno od Ernad Husremović prije više od 13 godina
Rezime¶
Završiti ovo - uraditi obje opcije:- napraviti jednu verziju fmk_migrate brancha u koju ćeš staviti idradnal
- napraviti fmk_migrate
tako da ćemo imati sav potreban arsenal za migraciju
Izmjenjeno od Ernad Husremović prije više od 13 godina
- Prioritet promijenjeno iz Urgentno u Odmah riješiti
završiti ovo dok je vruće, da možeš bez skakanja uzeti realizaciju FAKT NG
Izmjenjeno od Ernad Husremović prije više od 13 godina
~/dev/knowhowERP/fakt/chs$ grep -i -r "idrnal" *
faktrn.chs:A IDRNAL C 10 0 faktrn.chs:A IDRNAL C 10 0
pripr i fakt
Izmjenjeno od Ernad Husremović prije više od 13 godina
FMK fakt
~/dev/knowhowERP/fakt$ grep -i -r "idrnal" *
chs/faktrn.chs:A IDRNAL C 10 0
chs/faktrn.chs:A IDRNAL C 10 0
dok/1g/knjiz.prg: AADD(ImeKol, { "Rad.nalog", {|| idrnal}, "idrnal" })
dok/1g/knjiz.prg: @ m_x + 8, col()+2 SAY "R.nal:" GET _idrnal ;
dok/1g/knjiz.prg: VALID P_RNal(@_idRNal) PICT "@!"
dok/1g/stdatn.prg:// ako je rijec o radnim nalozima postavi filter u tabeli FAKT na polje idrnal
dok/1g/stdatn.prg: cFilter+=".and. FAKT->idrnal="+Cm2Str(cRadniNalog)
dok/1g/stdok2.prg:elseif (lTrebovanje .and. !Empty(pripr->idRNal))
dok/1g/stdok2.prg: cStrRN:=TRIM("PO RADNOM NALOGU br. "+pripr->idRNal)
dok/1g/stdok23.prg:elseif (lTrebovanje .and. !Empty(pripr->idRNal))
dok/1g/stdok23.prg: cStrRN:=TRIM("PO RADNOM NALOGU br. "+pripr->idRNal)
dok/1g/stdokpdv.prg:if pripr->(FIELDPOS("idrnal")) <> 0
dok/1g/stdokpdv.prg: if !EMPTY( pripr->idrnal )
dok/1g/stdokpdv.prg: add_drntext("O01", ALLTRIM(pripr->idrnal) )
dok/1g/stdokpdv.prg: add_drntext("O02", GetNameRNal( pripr->idrnal ) )
dok/1g/vknjiz2.prg: _field->idRNal:=_idRNal
rpt/1g/rpt_kart.prg: cFilt1+=".and. idrnal="+Cm2Str(cRadniNalog)
Izmjenjeno od Ernad Husremović prije više od 13 godina
Saša Vranić je napisao/la:
prije je to bilo polje fakt_doks->idradnal
ovo si ti napamet izgleda stavio ovakvo polje ja nigdje nisam našao.
Takođe, funkcija filtera koja je postavljena, kada faktura ima više stavki garant ne radi.
generalno je ovo baš loše urađeno - ostavljene stara imena varijabli cRadniNalog (što to je super stvar za zbunjivanje čitaoca koda)
Izmjenjeno od Ernad Husremović prije više od 13 godina
ono što je najveća zamjerka je to je to sve "nasuho" realizovano, bez adekvatnog testa.
Izmjenjeno od Ernad Husremović prije više od 13 godina
- Status promijenjeno iz Dodijeljeno u Zatvoreno