Bus apskaitos politikos keitimas, teoriškai įsakymu, keičiančiu apskaitos politiką.
Be kita ko, tokiu atveju modifikuosis inventorizacijos kontavimas, reikės papildomos sąskaitos žaliavų normatyvinei savikainai, kurią inventorizuojant reikės balansuoti su pardavimų sąnaudų sąskaita.

Ištaisiau, klaida buvo.
Vedant ranka reikia atsižvelgti į jau panaudotą NPD, kuris minusuojasi perskaičiuojant, t.y. ranka galima nurodyti visą tam mėnesiui taikytiną NPD, įskaitant panaudotą.

Apgaudinėti nereikia, npd stulpelį galima ranka redaguoti, ryt pažiūrėsiu, kaip ten skaičiuoja.

Tai kad NPD ir PNPD skirtinguose stulpeliuose...
Be kita ko, galima NPD ir ranka pakoreguoti.

Nelabai čia ką paaiškinsi, kažką prisižaidėt su serveriais. Serveriai iš prigimties bjaurūs iš/per instaliavimo atvejais. Kaip tik dėl to naujoj versijoj baziniu atveju jokių serverių nebėra. Čia jau be labai gerai draugaujančio su kompais pagalbos neišsiversit.

Sukurti gaminio kotelę/kalkuliaciją, joje nurodoma sudėtis, t.y. iš kokių sąskaitų kiek LTL paimti sąnaudų ir kiek kokių "detalių" nurašyti. Toliau Prie gaminamos prekės operacija gamyba pgl sukurtą kalkuliaciją.

Smulkmena, kada nors vėliau pataisysiu.
Įmečiau atnaujinimą su SAM v.3 generavimu pgl. tarifą.

Galima patikslinti, kas rodoma neteisingai?..
Deklaracijoje meta warningą priede, jei suma su mokesčiais kart atitinkamas tarifas duoda skaičių su kableliu.

Gal ir pritaikyčiau, priklausomai nuo darbo kiekio ir apmokėjimo santykio

Čia jau tikrai taip bus, ar sodra dar sugalvos ką nors genialiai idiotiško?

Nebus, reikia daryti atskirus žiniaraščius skirtingais tarifais. Jei pradėsiu varneles įvedinėti po kiekvieno valdžios "matematinio šedevro", po poros metų programa pasidarys nebeįmanoma naudotis dėl begalės varnelių.
Galima dar būtų išskirti mokestinę schemą į atskirą objektą, bet tas vėlgi labai apsunkintų programos vartojamumą. Bent kol kas šitoj vietoj nekeisiu nieko, tik reikia išsiaiškinti, ką tokiam bardake su sodros deklaracijomis daryti.
Pradėjau daryti FR0572 v.4 ir negaliu atsigrožėti autorių imbecilumo laipsniu. Suma su centais, išskaičiuotas mokestis - be, jei nesutampa centų tikslumu padauginus iš tarifo, forma warning'ą meta...

Dar klaidų aptinkama, tvarkau.

USB rakte įdiegti galima, bet yra du bet:
- nebus automatinio atnaujinimo (nors tą iš principo lengva parašyti);
- duomenų perkėlimas tarp mysql serverio ir lokalaus režimo paprastuoju būdu neįmanomas, reikia susirasti google konverterį sqlite<->mysql.(gal kada vėliau parašysiu)

Kam to reikia, jei ne paslaptis?..

Geriau to nedaryti, o naudoti interface'us, susiprogramuoti maper'į tarp apskaitos verslo objektų ir išorinės sistemos verslo objektų. Dirbant tiesiai su DB galit nesunkiai apskaitos logiką sugadinti...
Pats dariau integraciją su magento, bet nesu iki galo patenkintas savo sprendimu.



Kiek įmonių, tiek ir duombazių, neskaitant tiesiogiai su programa nesusijusių mysql sisteminių duombazių.
Naujoje versijoje dar yra security duombazė, kurios vardo bazės paskutinės trys raidės pakeistos į sec, pavyzdžiui, apskaita01 ir apskasec. Vardo bazė naujoj versijoj nebūtinai apskaita.

Žiniaraščius su skirtingais tarifais, dėl SODROS deklaracijų dar nesugalvojau, kaip šitą reikalą realizuoti...

Tikiuosi, kad ne. Prikišau nagus, kur kišti nereikėjo.
Įdėjau atnaujinimą su gyventojų tarifais. Šalia kitų išmokų gyventojams meniu punkto atsiras tarifų meniu punktas.

Suminė apskaita puikiausiai gaunasi naudojant paslaugas vietoj prekių. Vienetų kiekį rodyti realų, kainą faktūrose taip pat realią, laikotarpio pabaigoje galite išsitraukti pirkimus ir pardavimus pgl "paslaugas" ir vienu bž įrašu uždaryti sau susirašant buh pažymą su uždarymo paaiškinimu.

Būtų dar trumpiau, jei parašytumėt, į kokį dropboxą, kokius procentų pasirinkimus sukrauti, įvertinant tai, kad kažkas tvarkys ir praėjusius laikotarpius.

Gal dafai nespėliosiu, programa daugiau ar mažiau suprantamai pati paaiškina, kas ir kodėl jai nesigauna.

Paleisti programą su "Run as administrator" (to reikia tik atkūrimui iš atsarginės kopijos dėl langinių saugumo paranojos).

Metodom naučnogo tika taisyti kompo regioninius nustatymus ir žiūrėti, kada programa nustos keiktis...

O gal galėtumėt duoti pilną galimų/reikalingų tarifų sąrašiuką pgl rūšis?..

Bendras\DB struktūra -> Tikrinti ->Taisyti

Įmečiau atnaujinimą dirbantiems su prekėmis.
Atnaujinimas prasmingas kombinacijoje su indeksavimu.
Siekiant pagreitinti prekių operacijas/ataskaitas po šio atnaujinimo instaliavimo reikia prisijungus prie reikiamos įmonės per Bendras\Query browser įvykdyti šias dvi komandas (be kabučių su kabliataškiu paeiliui po vieną):

"ALTER TABLE prekes_op ADD INDEX `ParentID`(`P_ID`);"

"ALTER TABLE prekes_ko ADD INDEX `ParentID`(`P_ID`), ADD INDEX `ChildID`(`I_ID`);"

Testuota šitas reikalas tik vienoje sistemoje, pagreitino apie 20 kartų.
Indeksavimas nusimuša po duombazės atkūrimo iš atsarginės kopijos, t.y. po atkūrimo reikia įvykdyti šias komandas iš naujo.

Kompo regioninių nustatymų problema, kažkas gudraus padaryta, kad programa nebegali atsirinkti taško ir kablelio santykio.

O prekes naudojat?

Priklausomai nuo tingėjimo laipsnio ir testuotojų iniciatyvos. Kažkaip iš parsisiuntusių testavimui viso labo 2 vnt. testuoja, žodžiu, vangiai procesas vyksta.

Kas būtent neina?
Šiaip nežinau pokyčių, bet jei kintamieji nepasikeitė, formulė koreguojasi darbuotojų nustatymuose labai paprastai...

Kaip tai nėra?