F18

objasni kako se to sada koristi sa FMK, opiši, referenciraj se na releventne dijelove FMK koda

isto kao i za rnal, napravi video od par minuta

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.

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

ova funkcionalnost je najbitnija magacioneru jer to njemu služi da zna šta je isporučeno prema objektu itd...

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

očeivao sam da ćeš prvo završavati čagu ?

upravo uzimam to za čagu, nego ovo mi je friško pa samo da ispišem

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)

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 ?

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

ne nemaju, to je hano baza

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()
. ....
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 ?

Praktično je to neovisna opcija...

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...

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

Jedino ostaje pitanje gdje pohraniti podatak o samom objektu na nivou dokumenta, u fakt_atribute kroz prvu stavku dokumenta ?

prije je to bilo polje fakt_doks->idradnal

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

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

znači

- konkretno dodati idradnal u txt kao _memo [ 20 ]
- uvijek u txt polje, prva stavka upisati sadržaj tih 20 parametara

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)

"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

commit

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

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

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.

ispis objekta na dokumentima txt, odt...

filteri kod pregleda dokumenata po objektu itd...

commit

ostalo jedino da se napravi skripta koja će napraviti kopiranje ovih podataka iz fakt_doks->idradnal u txt memo polje za sve dokumente

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

najbolje napravi to odmah dok si "vruć" sa opcijom

commit

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

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

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.

da, ali treba i na dbf strani, radi semafora, između ostalog lokalni dbf se gleda

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

Time se ne remeti lokalni fakt_doks dbf niti se mora paziti na semafore

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.

samo navedi verziju baze i verziju F18 koji se treba koristiti za migraciju

testiraj i ovo je sve spremno

to nije nikada portirano na f18 bazu od samog početka

jer to polje nije bilo niti u inicijalnoj verziji dbf-a nego je bila posebna modifikacija struktura kojom se to dobivalo

masu polja sam ja naknadno uvodio iz tih modifikacija kada smo uvodili f18 bazu, nakon prve inicijalne

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...

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

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

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

"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

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.

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)

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.

ovo F18_migrate_dbf svakako je serviseru može biti dobar pomoćni alat. napravi ovako

da, to je pametnije, možeš odraditi modifikaciju, odraditi neku konverziju posao, zatim odraditi kontra modifikaciju da se vrati na prvobitno stanje

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

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

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

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

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.

Rezime¶

1. napraviti jednu verziju fmk_migrate brancha u koju ćeš staviti idradnal
2. napraviti fmk_migrate

tako da ćemo imati sav potreban arsenal za migraciju

~/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

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)

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)

ono što je najveća zamjerka je to je to sve "nasuho" realizovano, bez adekvatnog testa.