Žinau lietuvių, kurie tik per internetinius užsakymus pasidaro po 4 - 6 t. per mėnesį, taigi turint proto ir žinių viskas įmanoma.

PayPal yra tik vienas iš galimų variantų, yra ir daugiau ir geresnių internetinių mokėjimo sistemų, bet čia jau reikėtų pasiknaisioti internete ir palyginti. Internetinės mokėjimo sistemos turi vieną trūkumą, kiek žinau, jos netinkamos naudoti atsiskaitymams iš Lietuvoje registruotų įmonių.

Jei labai mylite valstybę ir esate pilietiškas, niekas nedraudžia įsiregistruoti individualią veiklą, deklaruoti savo pajamas ir mokėti mokesčius. Galima net UAB įsteigti.

niekaip (absoliučiai rimtai).

"Sistemos" rent a coder, jei suprantate angliškai, reiškia nusamdyti (išsinuomoti) programuotoją (plačiaja prasme). Tai viso labo turgaus tipo internetiniai puslapiai, kuriuose skelbiamos užduotys ir siūlomas atlygis. Freelanceriai tokiuose puslapiuose registruojasi ir mėgina gauti užsakymus pgl savo specializaciją. Pats puslapis geriausiu atveju veikia kaip depozitoriumas užtikrinantis užsakovo ir freelancerio tarpusavio įsipareigojimų vykdymą.

Visos tokios sistemos yra tarptautinio pobūdžio, nes visas bendravimas vyksta išimtinai elektroniniu būdu. Kurti kažką panašaus LR ribose nėra jokios prasmės, rinka švelniai tariant per maža.

Tą pačią schemą pritaikyti kitokiems darbams (dirbamiems ne elektroniniu būdu) nelabai įmanoma ir prasminga.

Praktiškai daugelis vienaip ar kitaip uždarbiaujantys internete niekaip "nesilegalizuoja" ir tam nėra absoliučiai jokios prasmės, jei tavo klientai yra ne LR įmonės.

Primityviausiu atveju, jei pajamos neviršija 100 t. Lt. pakanka atsidaryti e-atsiskaitymų accountą (paypal ir pan.), klientų pinigus nukreipti į šį accountą, o iš jo persivedinėti į savo kreditinę kortelę kaip sąskaitos papildymą. Šiuo atveju VMI net netyčia aptikus įtartinus pinigų srautus (kas yra labai mažai tikėtina), jiem tiesiogine to žodžio prasme neapsimokės kapstytis. Inetinės mokėjimo sistemos pasižymi net didesniu konfidencialumo lygiu nei daugelis bankų. O LR ribose VMI tematys tik pervedimus iš SAVO sąskaitos e-mokėjimo sistemoje, į SAVO sąskaitą LR banke. Ir kas svarbiausia - visa schema funkcionuoja absoliučiai nemokamai.

Kiek sudėtingiau ir brangiau išsiimti kreditinę kortelę, pavyzdžiui, Panamos banke, toliau veikia ta pati sistema tik LR bankų sistemoje apskritai nelieka jokio pėdsako. Tiesa gryninimo mokestis nuo panamietiškos kortelės LR sudaro nuo 2 iki 5 proc. sumos. Šita sistema sėkmingai veikia prie apyvartų iki ~1 mln. USD per metus. Nuostabu, bet daugumoje ofšorinių šalių banko korteles galima užsisakyti elektroniniu būdu ir gauti paprastu paštu (tiksliau DHL). Šito malonumo kaina dviem metams nuo 500 iki 1000 Lt.

Jei labai sena (>~1,5 m.) nebesutaps duomenų saugojimo logika, todėl programa nebesupras sena programos versija išsaugotų duomenų. Tas pats liečia ir tokia sena programa sukurtas duombazes bei jų kopijas.
Kitais atvejais update'ai susitvarko, bet DB tikrinimas yra reikalingas. Po dabartinės bazinės versijos išėjimo buvo du ar trys duombazių struktūros pekeitimai (nekeičiantys duomenų saugojimo logikos). Būtent jiems ir būsimiems pakeitimams reikalingas DB tikrinimas. Atkūrimas iš atsarginės kopijos atkuria tokią DB struktūrą ir turinį, kokie buvo išsaugojimo metu. Jei išsaugojimo metu buvo naudojama senesnė programos versija, galimus struktūros neatitikimus sutvarkys DB tikrinimas.
Ateityje naudojama duombazės struktūra keisis (kuo daugiau galimybių programoje, tuo daugiau lentelių ir laukelių duombazėje), bet suderinamumas išliks.



Galėtų būti ir kitaip. Tiesiog tokia struktūra "pakliuvo po ranka", kai rašiau šitą modulį. Kai turėsiu laiko, prie šio klausimo grįšiu. Dabartinis pelno (nuostolio) ataskaitos struktūros valdymas kiek nepatogus.[/b]

Nereikia nieko perinstaliuoti ar atnaujinti, tiesiog eikite į Bendras\DB struktūra, spauskite "Tikrinti", tada atsiras lentelė su visais duombazės trūkumais, tada spauskite "Taisyti".

O kada paskutinį kartą atnaujinote programą (išskyrus šį kartą) ? Ar naudojote avansų apyskaitas prieš paskutinį kartą išsaugodama atsarginę kopiją?



O lentelę kokiu būdu pradanginti sugebėjote? Ką darėte prieš atsirandant šiai klaidai?
Kažkokiu būdu sunaikinta duombazės lentelė, kurioje buvo (arba ne) visų kontrahentų duomenys. Programa nė iš tolo panašių komandų nenaudoja, neįsivaizduoju kaip tą padarėte.

Abiem atvejais Bendras\DB struktūrą, "Tikrinti", "Taisyti". Prieš taisant būtų smalsu pažiūrėti, kokios dar klaidos duombazėje. Jei nesunku, eksportuokit į excelį ir įdėkite čia.

Dar aptikau klaidą atkūrimo procedūrose. Buvau nenumatęs vieno galimo scenarijaus. Update'as čia:
http://cid-061b6c20c4d4f14d.skydrive.live.com/self.aspx/Vie%c5%a1asis/Apskaita%7C_1.1%7C_beta%7C_update.exe

P.S. Teoriškai tais atvejais, jei programa aptinka, kad serverio duombazėje tuo pačiu pavadinimu saugomi kitos įmonės duomenys arba atkuriamos įmonės duomenys saugomi kito pavadinimo serverio duombazėje, gali kilti bėdų su lietuvybe. Tai priklauso nuo vartotojo sistemos konfiguracijos (default'inių koduočių lentelių), taigi tokios galimybės visai pašalinti negaliu. Jei atkuriant duombazę pas ką nors dingtų lietuviškos raidės, vienintelė išeitis atkūrimas rankiniu būdu. Bet tai neturėtų būti dažna situacija.

Tai yra duomenys ar ne?

O atkūrimo metu kokią nors klaidą išmetė?

Update'as tai visiems skirtas.
"Įsikėliau kopiją" reiškia atkūrėte iš atsarginės kopijos?
Pabandykite išjungti programą ir vėl ją paleisti.

Aha, keistas toks padaras

Update ištaisyta:
1. Padidinta maksimalūs įmonės kodo ir PVM kodų laukelių ilgiai (nors naudoti programą individualios veiklos apskaitai vis tiek nerekomenduoju);
2. Sutvarkytos problemos su korespondencijų sąrašų controlsu;
3. Pridėtas patikrinimas atkurtiant duombazę iš atsarginės kopijos, kad netyčia neperrašytų "ant" kitos įmonės duombazės viršaus.

Update'as čia:
http://cid-061b6c20c4d4f14d.skydrive.live.com/self.aspx/Vie%c5%a1asis/Apskaita%7C_1.1%7C_beta%7C_update.exe

Gal galite tiksliau nurodyti, ką pasirinkus, ko ir kaip neleidžia taisyti.
Jei paclickinus ant BŽ operacijos pasirinkote ne "taisyti", o "korespondencijos", tai ir neturi nieko leisti. Šis pasirinkimas skirtas tam, kad peržiūrėti dokumentų (SF, DU žiniaraščio ir t.t.) suformuotas korespondencijas, o ne jas taisyti.



Kažkas padaryta su regional settings. Pas mane puikiausiai supranta sumas nepriklausomai nuo to, ar tūkstančiams naudojamas taškas, ar kablelis. Nebent gali būti susiję su kita klaida, kurios ištaisymą dabar įkraudinėju. Jei nepadės, reikia pasikapstyti po regioninius nustatymus.

Nieko panašaus pas save padaryti nepavyko. Jei beckupas darytas per programą to paties serverio atžvilgiu, viską atkuria normaliai ir niekas niekur nedingsta. Galėjo būti problemų tais atvejais, jei atsarginė kopija naudojama duomenų perkėlimui iš vieno serverio į kitą. Šitą išsprendžiau, šiandien kiek vėliau įdėsiu su update'u.

Parašykite, koks klaidos stekas (klaidos žinutės apačioje galima atidaryti papildomą langą).

Gal aš kažką ne taip supratau:
- darau darbuotojo detaliųjų duomenų įrašą atleisti 12-23;
- formuoju avanso žiniaraštį tam darbuotojui 12-04, 1000 Lt. sumai;
- registruoju avanso išmokėjimą tą pačią dieną;
- formuoju DU žiniaraštį tam darbuotojui 12-23, priskaičiavimai (į rankas) sudaro 999,9 Lt., mokėtina - 0 Lt.;
- tą pačią dieną registruoju DU išmokėjimą.

Rezultatas deklaracijoje visiškai teisingas, mano atveju 1254,1 Lt.

Ką šitoje sekoje Jūs padarėte kitaip?

Aš nežinau kokiu case'ingu linux sukuria duombazės pavadinimą, lentelių pavadinimus ir laukelių pavadinimus. SQL sakinys parašytas neteisingu case'ingu linux yra nesuprantamas arba duoda neteisingą atsakymą.

Vat čia ir šuo randasi. Linux yra casesensitive operacinė, windowsai - ne. Programa kol kas nesusikalba su *nix sistemomis būtent dėl šios priežasties. Aš pats negaliu to sutvarkyti, nes visiškai nesigaudau *nix sistemose ir neturiu ant ko bandyti. Prieš pora savaičių su manim buvo susisiekę programeriai su ta pačia problema. Žadėjo patys sutvarkyti ir persiųsti reikalingus kodo pakeitimus, bet kol kas jokių žinių nesulaukiau.

Tai jeigu prašote programos sukurti naują duombazę, nėra ko stebėtis, kad ji kaip tik tai bando daryti

Jau egzistuojančios įmonės DB, su sąlyga, kad prisijungęs prie programos vartotojas turi bent usage privilegiją į jas (t.y. duombzių sąrašas grąžinamas į SHOW DATABASES), iš karto po logino turi atsidurti įmonių sąraše. Gal ant serverio ne windowsai sukasi arba mysql versija ne ta?

Jeigu klaida skamba "Access denied for user username@ip to database apskaita01", reiškiasi duombazė "apskaita01" egzistuoja, bet duombazė yra įsitikinusi, kad vartotojui username@ip nepriklauso prie jos kišti nagus. Programa čia tikrai niekuo dėta.

1. Būtų gerai pamatyti ilgesnį steko gabalą;
2. Kuriuo momentu (ką darant) meta klaidą?
3. Ar sukūrus vartotoją flush'inot privilegijas arba restartavote serverį?
4. Ar programa per vartotoją username@ip mato ir prisijungia prie rankiniu būdu sukurtų duombazių?

Jei serveris prieinamas per inetą, atsiųskite privačia žinute prisijungimo duomenis, bandysiu pasiknaisioti.

O ką rašo neleisdama?

Atsargiai su tokiais grantais, ypač jei useris turi teisę jungtis iš bet kurio nutolusio kompo (ip %). Galima užsirauti ant kokio kirmino.

Beje, rankiniu būdu kuriant userius (insertinant į sisteminę duombazę), reikia padaryti berods flush privileges, serveris automatiškai nepasiima naujų duomenų. Arba saugiausia naudoti grant privileges sintaksę. Tai bent jau nepalieka galimybių ką nors pridirbti sisteminėje duombazėje.

Žaidžiam su sql
Žinoma, kad access denied prie duombazės, sukurtos per skriptą. Vartotojui reikia atitinkamus grantus suteikti. Įtariu gavosi taip, kad username turi grantą usage, bet neturi granto select.
Geriau jau nudropinkite visas duombazes (išskyrus mysql sistemines žinoma) ir tada jau kurkite per programą. Arba skaitykite kokį mysql administravimo tutorialą.

Pažiūrėsiu vakare

Ir dar. Kuriant įmonių DB iš skripto, reikia papildomai insertinti vieną eilutę į lentelę imone, toje eilutėje privalo būti užpildyti laukeliai, identifikuojantys įmonės pavadinimą, adresą ir kodą (I_Pavadinimas, I_Adresas, I_Kodas), t.y. NOTNULL laukeliai.

Sukuriau apskaita01-apskaita09, ivedant imone sako nera apskaita10. Kiek jam reikia? Jokiu duomenu bazeje nera.[/quote]

Šiaip tai gali ir visai nebūti duombazių, svarbu tik, kad neatsirastų duombazių, kurios prasideda žodžiu "apskaita", o baigiasi ne skaičiumi. Nelabai suprantu, ką turite omenyje "sako nera apskaita10"...

DB name turi būti apskaita01, apskaita02 ir t.t. Todėl ir klaidą meta.



CHM
http://cid-debf1c7c4bc2b88c.skydrive.live.com/self.aspx/Vie%c5%a1asis/Apskaita|_Help.zip

PDF
http://cid-debf1c7c4bc2b88c.skydrive.live.com/self.aspx/Vie%c5%a1asis/Programos%20zinynas.pdf

Dėkokite ZaraRola už didelį darbą. Galėtų ir dar kas prisidėti tobulinant helpus. Darbas tikrai nereikalauja jokių ypatingų žinių - pakaktų ir word formato.



O Ctrl-C ir Ctrl-V kam skirti (galima ir pele, jei taip patogiau)? Nelabai noriu palikinėti duomenų, nes kitą kartą toks palikimas gali būti klaidingas.

Dabar ne, bet jei atsiųsite word arba excel formatu formas, galiu padaryti.

Tinka, tik tingėjau perkompiliuoti install'ą, gal ryt perkompiliuosiu ir įmesiu.

Programa tokios logikos nepalaiko.

Esmė tame, kad per vieną sąskaitą išsifiltravus tiekėją turi matytis visi to tiekėjo pirkimai ir atsiskaitymai. Jei avansinius atsiskaitymus iškeliame į kitą klasę, nebeturime vienos ataskaitos, o duomenys tampa išsisklaidę per dvi vietas. Tas nėra nei gerai, nei patogu.

Jei jau labai norite naudoti 2 klasėje apskaitomus išankstinius mokėjimus, teks papildomai registruoti BŽ įrašą: D 4___ tiekėjai, K 2___ išankstiniai atsiskaitymai.
Bet paprasčiausia visus mokėjimus įskaitant avansinius rodyti per vieną 4 klasės sąskaitą. Tada visą atsiskaitymų balansą bet kuriuo metu matysite viename sąskaitos apyvartos žiniaraštyje.