treba vidjeti za ovaj SII, on je identičan OS-u, samo da se uvede marker u polje sredstava koje će određivati OS ili SII

to sam i prije 5 godina isto govorio, jednostavno glupaština duplog kod-a

analiziraj korisnike koji koriste SII.

Portiranje uradi uzevši u obzir cilj da je njima potrebno obezbjediti aplikaciju sa kojom će nastavirti raditi ovu evidenciju.

šta se razlikuje kod SII u odnosu na OS ? Neki izvještaji ?

Ništa se ne razlikuje, samo header, umjesto OS piše SII :)

mi smo korisnici SII + OS.

Eto pripremi naše podatke. Ako može bez duplanja koda obezbjediti potrebne funkcije to je to.

Što se tiče markiranja OS/SII, to "markiranje" se radi putem konta. Tako da bi trebalo biti dovoljno spojiti podatke.

Razgovarao jutros sa željkom na ovu temu, pa kaže da su navodno brojevi koje koristimo

SII

X000150
X000151

OS

X000152

SII

X000153
X000154

itd...

tako da ne bi trebalo biti duplanja, ali treba provjeriti. Ona to sve ima u onom spredsheet-u u koji prvo unosi podatke, i tu postoji podatak da li je neko sredstvo OS ili SII također, tako da definitvno ne bi trebalo da se duplaju podaci.

Saša Vranić je napisao/la:

Razgovarao jutros sa željkom na ovu temu, pa kaže da su navodno brojevi koje koristimo

SII

X000150
X000151

OS

X000152

SII

X000153
X000154

itd...

tako da ne bi trebalo biti duplanja, ali treba provjeriti. Ona to sve ima u onom spredsheet-u u koji prvo unosi podatke, i tu postoji podatak da li je neko sredstvo OS ili SII također, tako da definitvno ne bi trebalo da se duplaju podaci.

za konkretnog klijenta, makar što se radi o nama, otvori poseban ticket na internom "knowhow ERP" području.

Ovo su informacije koje ne pripadaju ovom ticketu.

prateći vezni ticket zaključio sljedeće:

1) migracija podataka mergiranjem može stvoriti komplikacije. ako se tome doda da je uopšte upitan model podataka OS/SII ulaganje napora u smjeru mergiranja SII/OS u jednu tabelu ne izgleda pametno

2) SII, OS u aplikativnom smislu su jedna aplikacija

iz gore navedenog mislim da je optimalno rješenje sljedeće:

1) OS/OS_PROMJ su dvije tabele u kojima se nalaze podaci

2) uvesti SII/SII_PROMJ

3) F18 modul nazvati: "OS/SII"

4) kod ulaska u modul omogućiti korisniku da odabere rad sa OS ili SII podacima

5) tokom rada koristiti tu postavku modula za otvaranje OS/OS_PROMJ odnosno SII/SII_PROMJ tabela.

Kako realizovati 4) i 5) ?

Na stari način sa globalnom varijalbom gOS_SII = "O" / "S"

1) Uvesti globalnu varijablu gOSSII

2) kod ulaska zapamtiti (na user nivou) posljednji odabir

2) tokom otvaranja koristiti ovu varijablu za otvaranje OS ili SII u O_OS, O_OS_PROMJ

jeste

tj, treba vidjeti i OS modul da li je sada ok

Prvo očistiti dosadašnje radove, ovdje se koriste neke ranije funkcije za update na server ono f18_gather, f18_scatter

čim bude u iskoristivom stanju napraviti build da vzeljka može završiti knjiženja 2011

kreiranje tabela - rewrite

znači sada kreiramo tabele:

• OS_OS
• OS_PROMJ
• SII_SII
• SII_PROMJ

u O_OS, O_PROMJ sada treba na osnovu globalne varijable znati otvoriti potrebnu tabelu

Ernad Husremović je napisao/la:

čim bude u iskoristivom stanju napraviti build da vzeljka može završiti knjiženja 2011

a ha, trebao sam onda prije ovoga ... dobro

Ciscenje niza funkcija i stavljanja u funkciju OS-a scateri, gatheri itd...

commit

Trenutno ostavio da se kreira kao i do sada da bih napravio ovaj build...

Saša Vranić je napisao/la:

Trenutno ostavio da se kreira kao i do sada da bih napravio ovaj build...

nisam te razumio šta si htio reći

ma nisam pravio sii tabele, to ću nakon ovog build-a

aha da može se unijeti OS. dobro si.

ma ja

commit

čišćenje unosa promjena, otpisa itd...

parametri, setovanje i čitanje iz sql/db

parametre organizacione jedinice nisam dirao, to treba da ide sa glavnog mjesta... onaj jedinstveni

parametar koji određuje rad OS ili SII sam uveo i nalazi se na prijavnoj masci... također se smješta u parametre po useru zajedno sa datumom obračuna

hm, šta uraditi sa OS početno stanje opcijom ???? u principu treba je osposobiti da ne radi ona prebacivanja nego samo da odradi setovanja otpisane vrijednosti u polje u OS.DBF-u

U OS-u su bila 2 koraka

• OSPREN - prenos iz sezone u radno područje - to nam sada ne treba !!!
• OSGEN - to je setovalo otpise itd... - to nam treba srediti također

Osposobio opciju "OSGEN", ovu za prenos izbacio...

commit

Također ispravio grešku kod unosa osnovnih sredstava, polje K1 nije htjelo da se ažurira i incijalizuje iz šifrarnika

Eh, to je sada spremno za unos OS-a i obračun amortizacije.

sad ću napraviti build

Eh, sada se treba poigrati sa ovim tabelama...

napraviti nove tabele na sql/db-u i lokalne i napraviti ovu metodu svičanja na osnovu parametra

SII tabele¶

napravio kreiranje SII tabela pored OS tabela - to je ok

napravio semafore SII tabela, pune se - ok

commit

Eh, šta je problem !!!

Kada sam u SII šifrarniku i dodajem stavku, doda mi u DBF ali mi na sql strani doda u os_os tabelu umjesto u sii_sii

hm, zato što radi vjerovatno po alias-u, a alias je OS

To je problem sa funkcijom unutar codes_browse.prg

ona koristi alias(), to bi trebalo moći nekako setovati

mislim na ovo

e sada, da ne diramo te funkcije imamo drugo rješenje a to je:

napraviti p_os() funkciju za browse sredstava zaobilazeći postojisifra() funkciju nego koristiti objdbbrowse() i F2, brisanje napraviti sa box-ovima, kao što su to ugovori recimo

kreiranje tabela i semafori commit

mislim na ovo ...

hm pogledao sam. ali čačkanje po toj funkciji bi bilo nakarada teška.

fazon je što ti izazivaš popriličnu konfuziju i niz opasnosti u funkcija ako si ostavio alias identičan ... sada razmišljam.

za tren će ti neki podataka umjesto u os otići u sii tabelu.

tako recimo semafori ne mogu znati sa kojom tabelom rukuješ (na mnogim mjestima) ako koristiš alias os za os_os i sii_sii tabele

...

Tako mi se bar čini onako naglas razmišljajući. kod nisam gledao. ali mislim da mi se ne bi svidio.

znam da sam ja dao instrukcije za globalnu varijablu koja bi mijenjala tabele ... ali koliko god to bilo prljavo.

ovo korištenje istog aliasa za različite tabele nije dobra ideja ...

ja sam imao na umu da O_OS za gOSSII otvori jednu ili drugu tabelu ...

ali bi to trebalo biti ipak

da bude nešto kao:

if gOSSI = "O" 
  otvori OS alias os, OS_PROMJ alias os_promj
else
  otvori SI alias si_promj, OS_PROMJ alias si_promj
endif

naravno onda se u svakom selectu pojavljuje problem select os ili sii tabele ...

ovakav kod bi bio dovoljno "čist":

// otvori os_os, os_promj ili sii_sii, sii_promj ozvisno o globvar
o_os_sii() 

....

// selektuj os_os, sii_sii ovisno o globvar
select (os_sii())
...

// select os_promj, sii_promj ovisno o globvar
select (os_sii_promj())

to povlači mnogo promjena, ali se one sa find/replace mogu brzo uraditi ...

identičan alias masu problema u semaforima može stvoriti ... sigurno će stvoriti.

da, upravu si, tako ću i napraviti

to je sigurnije

napravio sam niz izmjena i spojio OS/SII

commit

commit

dakle, glavne funkcije koje moramo pozivati su

• select_os_sii()
• select_promj()

te funkcije za otvaranje tabela:

• o_os_sii()
• o_os_sii_promj()

jedan tipični scenario je:

O_KONTO
O_RJ
o_os_sii()  <--- ovo će otvoritili ili O_OS ili O_SII u zavisnosti od gOsSii parametra

select_os_sii()  <---- ovo će se pozicionirati na tabelu os ili sii u zavisnosti od parametra
_sr_id := field->id  ( moramo koristiti field-> umjesto os->id itd...)

select_promj()  <---- pozicionira se na tabelu os_promj ili sii_promj
hseek _sr_id

itd...

Imamo znači i novu verziju fmk paketa 4.1.9 gdje su dodane ove nove tabele...

korigovao sam sve izvještaje itd...

To bi sada trebalo da bude to !

Kod SII također stavio da se ne brišu sredstva kod generacije podataka u novoj sezoni.