O ką? turėtų suvaikščioti prieš tai?
Visose programose, įskaitant ir maniškę, didžioji knyga vedama visiškai automatizuotai. Tai vienas iš labai nedaugelio bendrų programų bruožų.
Vedama yra įvairiai, priklausomai nuo dokumento tipo.

Sic!
Esmė ne tame, kokiam subjektui konkreti įmoka/mokestis sumokamas, o tai, koks mokestinis teisės aktas tą įmoką/mokestį nustato. GPM, PVM, PM viskas mokama VMI, bet mokesčiai tai skirtingi. Taigi nuo 2009 ir čia turime skirtingus mokesčius - + 27,98 proc. SODRA = 30,98 proc. (jei įmonė neturi problemų su darbų sauga)

Kadangi komercines programas rašė programeriai, o ne buhalteriai, vienos bendros logikos (sistemos) jose nėra. Su kiekviena programa reikės mokytis dirbti iš naujo. Paprastai sakant duomenys visur vienodi, o pateikimo/įvedimo kampas visur skirtingas. Perėjimas nuo excelio prie mano programos yra gerokai lengvesnis, nei perėjimas prie bet kurios kitos komercinės programos. Bet perėjimas nuo mano programos prie bet kurios komercinės bus tikrai ne lengvesnis.

Stambiose įmonėse senas geras chronometravimas ir "kaštai plius pelno marža plius apyvartumo kompensavimas" logika. Smulkiose kainynų nėra - konkurentų kainų apžvalga, darbų apimtys iš akies plius kliento psichologijos įvertinimas. Viena man žinoma įmonė bandė įvesti apmokėjimą už BŽ operacijų vnt. ir dokumentų vnt., bet užsikasė beskaičiuodami ir beaiškindami klientams, kodėl tiek daug operacijų, ir grįžo prie seno gero abonemento.

Esmė yra apskaitos logikos suvokimas ir žinios, o ne tai, kur jos buvo įgytos. Koks skirtumas, kur žmogus žinias įgijo - universitete, kolegijoje, bibliotekoje ar namuose? Svarbiausia kad įgijo. Taigi jei jau licencijuoti, tai reikėtų egzaminuoti žinias, o ne tikrinti "popierių". Žinoma, Lietuvai toks supratimas svetimas, pas mus vyrauja ministerska logika "o kur popierius"...

O su "kvalifikaciją įrodančiu dokumentu" tai jau negali nukentėti...
Aš pats esu nudegęs su viena buhe, turėjusia VU diplomą ir žinau dar pora tokių pačių, kurių gyvenime net prie savo smulkių įmonių apskaitos neprileisčiau. Pažįstu ir vieną proftechninę baigusią buhalterę, iki kurios apskaitos supratimo ir gebėjimo mokytis pirmosioms kaip iki mėnulio. Dėl tokios patirties nemanau, kad reikėtų sieti buhalteriavimą su kvalifikacija, t.y. išsilavinimu. Nors nepriklausoma egzaminavimo sistema alia MCTS nepakenktų.

Šita klaida su nustatymais nieko bendro neturi. Ji reiškia, kad skaičiuojant DU kažkoks apskaičiuotas skaičius priartėjo prie begalybės. Pas mane nieko panašaus nemeta, taigi problema yra jūsų įvestuose skaičiuose. Jei atsiųstumėte to žiniaraščio skaičius, pažiūrėčiau kame bėda.

Taip.



Ką reiškia nereikia? Už 2009 ir vėliau reikia, taip seimas nusprendė. Už ankstesnius programa šį tarifą tiesiog ignoruoja ir nieko nepriskaičiuoja.

Chronologiškai paskutinis atnaujinimas šioje temoje - parsisiųsti ir instaliuoti.

Priklausomai nuo IT lik vertės ir remonto vertės santykio IT remontą galima apskaityti kaip savarankišką IT vienetą.
Registruojant gautą SF programa šiuo metu be reikalo neleidžia tiesiogiai debetuoti pirmos klasės (nesusidūriau, nepagalvojau, su sekančiu update'u leisiu). Apėjimas debetuoti kažką iš šeštos klasės, o tada BŽ įrašu nukreipti į IT apskaitos sąskaitą.
IT modulyje IT pervertinimo operacija yra nefinansinė, t.y. nėra vienareikšmiškai susieta su BŽ įrašu. Ją reikia įvesti papildomai tam, kad IT modulis žinotų apie vertės pokyčius įvairių BŽ operacijų pagrindu.

Kažkaip niekada neatkreipiau dėmesio į tokią išimtį. Tada gal iš viso nuimti IT surišimą su grupėmis? Išskyrus minimalius amort. laikus tos grupės lig ir neturi jokios prasmės.

Pabandžiau, viskas veikia normaliai. Kažkuriame update šitą klaida jau buvo ištaisyta. Gal neįsidėjote paskutinio update'o.

Parašysiu ryt poryt. Daugokai rašymo, vis patingiu. Gautai faktūrai 4 skirtingi insertai, išrašytai - 6.

Mano nuomone, taip negalima.

Naktinis, viršvalandinis >=150 proc.
Poilsio, švenčių >=200 proc.
Ypatingomis sąlygomis >100 proc.

Į programos funkcionalumą neįeina užsakymų valdymas.
Prekės gali būti pajamuojamos tik gavus tiekėjo SF, o tas jūsų atveju nesutampa su apsipirkimo eshope momentu. Prekės gali būti parduodamos tik po pajamavimo, o tas vėl gi nesutampa su apsipirkimo momentu.
Kad tokia sistema veiktų reikia:
1. Suprogramuoti papildomą modulį;
2. Sukurti elektroninę tiekėjų SF pateikimo sistemą, t.y. kad tiekėjai inetu arba emailu pateikinėtų sutarto formato SF.

Logika būtų daugmaž tokia:
1. Atskiroje DB lentelėje yra fiksuojamas užsakymas;
2. Programa informuoja apie užsakymą tiekėją;
3. Gavus tiekėjo elektroninę SF programa automatiškai susietų ją su užsakymu, generuotų pardavimo SF ir išsiųstų ją pirkėjui.

Neturiu, bet jei sukonkretinsit norus, galiu parašyti algoritmą.

Iki update'o DU žiniaraštis lūždavo, kada buvo bandoma skaičiuoti nesuvedus visų reikiamų parametrų. Dabar jo neleidžia atidaryti, kol nebus visos info nustatymuose. Be to, dėl skaičiavimo ypatumų priemoka už darbą ypatingomis sąlygomis turi būti >= 100 proc.

Susitarimas nereiškia, kad jis privalo būti rašytinis ir būtent darbuotojo pageidavimu.
Gali būti ir darbdavio pageidavimu darbuotojui raštu arba konkliudentiniais veiksmais sutinkant.

Šiaip jau joks teisės aktas nereikalauja, kad dėl atostogų suteikimo būtų rašomas būtent įsakymas. Tiesiog reikalingas koks nors dokumentas, patvirtinantis atostogų suteikimą. Jei yra raštiškas darbuotojo prašymas ir vadovo viza - įsakymo nereikia, t.y. neprivaloma. Jei yra įsakymas, darbuotojo prašymo nereikia, nors rekomenduotina susipažinimo parašas. Tas supaprastina gyvenimą smulkiose įmonėse. Aišku, stambioje įmonėje dėl organizacinių priežasčių geriau naudoti prašymo ir įsakymo komplektą.

"Product key" reiškia, kad Jums mandagia forma buvo pasiūlyta įsigyti legalią office versiją. Jei turite legalų kompaktą, paprasčiausiai vieną kartą įveskite ant jo nurodytą product key (berods penkios skaičių ir raidžių grupės po keturis simbolius). Jei neturite...

Nauja versija dar toli gražu nebaigta. Ir su mano užimtumu neturiu supratimo, kada baigsiu.

Ne ten vedate. Likučiai gryname pavidale vedami formos viršuje esančiuose 2 stulpeliuose. Apatinėje dalyje vedami tik analitiniai likučiai.

Tai priskirkit prie "tiekėjai"



Vienintelis būdas parodyti SF apmokėjimą grynais yra avanso apyskaita. Apmokėjimo data tam jokios reikšmės neturi.
Atskirais retais atvejais galima dar rodyti per KIO.

Arba pasižiūrėti lentelių ir laukelių pavadinimų case'inimą linuxe, padaryti atitinkamą replace'ą source ir susikompiliuoti tam serveriui tinkamą distribuciją. Nesu tikras, ar vienodas SQL scriptas ant visų *nix platformų realiai sukuria tokio pat case'inimo pavadinimus. Naujoj versijoj SQL užklausos saugomos atskirame xml faile todėl pasiekti suderinamumą bus sąlygiškai lengva be programavimo.

Registruojant IT (per SF ar kitaip) automatiškai įvedama viena operacija su tuo IT - amortizacijos laiko nustatymas. Prieš ištrinant IT, reikia šią operaciją ištrinti,

Gal. Bet reikia atrasti nemokamą hostingą su patogiu failų talpinimo/parsisiuntimo interface'u (kad net su kompiuteriais ir anglų kalba nesutariantys vartotojai sugebėtų parsisiųsti).

Įdedu naujos versijos programos kodą norintiems prisidėti prie programavimo.
http://cid-061b6c20c4d4f14d.skydrive.live.com/self.aspx/Vie%c5%a1asis/Apskaita5.zip

Problema tame, kad dabartinėje versijoje SQL yra hardcoded programos source. Tas daro ją nesuderinama su linux bazėje veikiančiais serveriais.

Update ištaisyta:
1. DU apskaičiavimo žiniaraščio spausdinama forma pakoreguota, išimta a.k. ir to sąskaita praplėsti kiti stulpeliai, įdėta visų priskaičiavimų suma žiniaraštyje.
2. DU žiniaraščio spausdinimas buvo jautrus regioniniams nustatymams. Dabar jau bus nebejautrus.
3. Įmonės duomenų formoje įkrovus didelį logo paveiksliuką jis uždengdavo įvedimo mygtuką.
4. Bendruose nustatymuose įvesta varnelė leidžianti pasirinkti, ar prieš paleidžiant DU skaičiavimo formą reikia rodyti nustatymus. (jei trūks skaičiavimui reikalingų nustatymų, formą rodys bet kuriuo atveju).

Update'as čia:
http://cid-061b6c20c4d4f14d.skydrive.live.com/self.aspx/Vie%c5%a1asis/Apskaita^_1.1^_beta^_update.exe