Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - RDa

Stran: 1 ... 132 133 [134] 135 136 ... 153
1996
Odkladiště / Re:Jak máte zařízené účetnictví?
« kdy: 05. 12. 2017, 21:12:41 »
Mně nejvíc děsí to, abyste podchytil v těch automatech chyby, které vzniknou po změnách. Změnami myslím aktualizace Pohody, změny v legislativě, chyby ve výstupech ostatních programů. Není nic horšího, než když zjistíte, že, například, 1/10 záznamů je zaúčtována blbě už několik měsíců nebo let.

Tohle ten muj system resi stylem ze se vzdy cela historie prepocita (zadne inkrementalni operace nad casti dat tam nemam umozneno a ani rucni override - cele ucetnictvi odpovida jednomu algoritmu, pak uz je otazka jak moc vetvenej a podminkovanej je..). A pokud spadne nejaka operace do jine "kolonky", tak je to videt v rozdilu vuci jiz podanym hlasenim. V tom pripade nastanou dve veci - pokud se jedna o nepodstatnou vec, jako napr. presun dph mezi ruznyma mesicema, tak na to kaslu. Pokud by to bylo neco podstatnyho, jako zmena danoveho zakladu tak muzu podat opravne hlaseni. Zatim to nebylo nutno, ale jako system se mi to osvedcilo u rocnich uzaverek - pridavanim pravidel pro novou legislativu se nesmi rozbit jiz podane hlaseni v minulosti.

Neco jako "zauctovana blbe" tedy z principu nehrozi - operace maji svuj fingerprint podle toho co/kam/proc a kdyz je spatne udelano zauctovani urciteho druhu dokladu, tak jsou vsechny spatne, nebo zadna spatne. Momentalni stav je 115 ruznych fingerprintu. Oprava je jen o zmene algoritmu a spusteni minutoveho procesu.

V klasickem ucetnictvi zalozenem na ucetnich osnovach se pak muzou ucetni podelat, kdyz nejake zauctovani podelaji :) Proto si stojim za svym, ze "jeden algoritmus vladne vsem". Neni mozne, aby stejna vec byla zauctovana dvakrat ruzne. Pokud musi byt zauctovana ruzne, tak to pak neni stejna vec.

1997
Odkladiště / Re:Jak máte zařízené účetnictví?
« kdy: 05. 12. 2017, 12:20:37 »
Z toho zaveru pouze vyplyva, ze musim vybudovat vetsi firmu, aby se to vyplatilo interne resit.

Taky to tak vidim, ze tohle by bylo reseni :)

@MS: ohledne problemu s exportem. FedEx vyridil celni deklaraci na vyvoz jako prodej namisto reklamace. Pry to od urciteho data nedelaji a maji automaticky takovy fallback. Bez upozorneni pro nas. Problem nastal v momente kdy se opravena vec vratila - a jiny deklarant se to snazil proclit jako opravu, nacez ho celnici vyfakovali, ze to neslo ven v rezimu na opravu, ale prodej. Takze jsme se dohadovali chvili - spravne reseni by bylo re-deklarovat ten puvodni export, ale to bud nelze nebo nechtel provest FedEx nebo by to neudelali celnici (pripadne az zadlouho*). Nakonec jsem pristoupil na variantu ze to znova kupuji za vyssi cenu, protoze stejne to bylo v 0% celni kategorii.

Tohle je proste pripad, ktery nevyresite aby vysledek vyhovoval zakonum. Nekdo udela chybu, jiny nedovoli chybu napravit. A odseru si to jako ja?

*) i mala oprava na JSD (protoze DHL nam neco automaticky proclelo podle malych cisel od cinana) trva cca 3 mesice - staci zadost o napravu poslat pres DS. Ale nevim zda by zruseni VDD a vytvoreni noveho proslo :) Chapu ze v tom pripade bych na zbozi z opravy cekal mesice a zaplatil za uskladneni.. pritom chyba byla na strane deklaranta. Ktery by mel byt odbornikem ve svem oboru. Zrejme neni - ani u tak velkych korporaci jako FedEx. Takze jsme zpet u toho - nikomu se neda verit, mame si vse delat sami?

Velice rad bych mel vse v poradku alespon z tohoto hlediska, ale nastroje na napravu neexistuji. Stacil by pritom jen slusny elektronicky system, kde si to vsichni naklikame. A taky to, aby nam stat veril a mohlo se to vyridit za hodiny namisto mesicu.

1998
Odkladiště / Re:Jak máte zařízené účetnictví?
« kdy: 05. 12. 2017, 00:27:37 »
Nevim tedy co by melo byt ono podivne hlaseni v SH, protoze cokoliv tam je, je u me normalni prodej a muzu dolozit prodej fakturou a vyvoz pres sledovaci cislo.

@MS: melo tam byt "nemeli by jste k tomu potrebovat", snad to pak dava smysl. Omezeny snad nejsem, ale chybka se sem tam vloudi. Kdo to neni schopen priznat a ani akceptovat, ten je pak omezeny. Proste mam za to, ze danovy system musi byt v prospech ucastniku onoho systemu. Nebo by nekdo chtel, aby si ajtaci zalozili podobnou lobby a na internet se uredne poustel jen ten, kdo mesicne, ctvrtrocne a rocne poda vykaz o sve tamni cinnosti? :)

@samoucetni: prave JSD je podle toho jak se celnik vyspi. Nekdy se akceptuji incoterms podle dokladu, nekdy si trvaji na svem ze to neuznavaj a ze to tak byt preci nemuze.. a pridaji tam svou bulharskou konstantu. Posledne jsem narazil s FedEx-em, ze pry uz nedelaji celni doklady k reklamacim.. a byt jsem poslal vec do ameriky jen na zaklade RMA, bez FA, tak to k celnikum nahlasili jako prodej. Takze tohle je taky voser.. clovek aby si vse delal sam :(

1999
Odkladiště / Re:Jak máte zařízené účetnictví?
« kdy: 04. 12. 2017, 21:29:02 »
V daňové oblasti Vás navíc chrání: 1) možnost zpracování daní poradcem

Dekuji nechci. Potrebuji se v tom vyznat i sam. Moje prvni zkusenost s ucetni totiz byla velice spatna - mel jsem prvnich par prodanych desek skrze PayPal a namisto toho aby tohle pochopila, vzala sumu kterou jsem si z PayPalu zaslal na ucet jako zaklad dane. Jako WTF? Tohle pako si dovoli rikat ucetni?? A brat si za to jeste penize???

Od te doby jsem sice mel nejake vysvetlovacky na FU, ale nastesti vse se vysvetlilo neznalosti a napravou - dnes jiz diky tomu vim jak se veci maji a zajimam se o princip fungovani. Vcetne vsech stupidit ktere system vyzaduje aby odevzdane hlaseni sedeli i na strane uradu (viz potize JSD).

Osobne tedy spoleham na to, ze to delam nejlepe jak to umim - a nikdy ne tak, abych se necemu vyhnul. To, ze je system zbytecne komplikovany si musi vyresit ale uz oni. Dane se proste tykaji kazdeho - stejne jako vymesovani - a k tomu snad zadneho odbornika, poradce ani auditora snad nepotrebujete.

2000
Odkladiště / Re:Jak máte zařízené účetnictví?
« kdy: 04. 12. 2017, 15:59:03 »
Jestli to negeneruje data podle zakona o ucetnictvi a ceske ucetni osnovy, tak to je jeste vetsi hardcore nez to nase; a popravde receno jsem rad, ze v tom "nejsem sam". Ty nase generuji alespon normalni ucetni denik.

Az zakon bude definovat presny algoritmus, budeme podle zakonu fungovat. Ale v momente kdy je interpretace zavisla na fantazii ctenare at se nikdo nezlobi, ze moje interpretace vedla k reseni ktere momentalne pouzivam. A pokud je potreba vyhovet pravnim predpisum, meli by byt v prvni rade dostupne a podruhe platnost indikovana. Clovek aby ty narizeni shanel jako matros na vyrobu drog po temnych koutech :/

Btw dennik mam generovany (vuci realnym uctum) a hyperlinkovany na vse relevantniho. To, ze zakonny system a lobbisticka skupina ucetnich vytvorila nejake virtualni ucty a dela v tom bordel neni muj problem - nejsem zatim v kategorii kdy bych potreboval danove optimalizace a ani po tom netouzim. Chci delat svoji praci (coz je vyvoj elektroniky), bohuzel se to dnes vic a vic toci kolem toho jak vse spravne uctovat.

S temi JSD je to nejvetsi bordel podle me. FU byl spokojen, jen kdyz jsem v kolonce dovozu uvedl sumu hodnot z vydanych JSD, protoze CU jim bonzuje tyhle agregovana data. To, ze ty cisla nemaji zadnou relevatni hodnotu jaksi nikoho netrapi.

@samoucetni: mohli bychom zalozit zajmovou skupinu nezavislych poctaru a sdilet metody jak co resit. Zajima me treba kam s rozdilem mezi JSD a realnou platbou (nemluvne o jinem kurzu, coz jsi uz otevrel) - oni tam velice radi prihazuji nahodne cislo, pry podil na doprave. A pak k cemu/proc/jak s tim MOSS.

2001
Odkladiště / Re:Jak máte zařízené účetnictví?
« kdy: 04. 12. 2017, 09:57:35 »
Ja to resim temer stejne jako autor - a mam stejne zkusenosti s ucetnimi - jakmile je tam zahranicni mena nebo PayPal, tak od toho davaji ruce pryc. Takze jsem si dal par konzultaci co kam patri a vlastne nedavna elektronizace DPH, KH, SH me donutila si to taky generovat.

Muj system (15K LoC v PHP) je nasledovny:
Zakladem jsou dva excel sheety, jedno obsahuje subjekty a druhe obsahuje samotne ucetni doklady. Format tohoto souboru je dost lidsky a puvodne slouzil jako podklad na rucni tvorbu priznani k DPH. Oboji se skriptem naimportuje do DB, z banky se taky importuji transakce ze vsech uctu (czk/eur/usd) a z PayPalu take. Pokladna a PayPal jsou vlastne multi-menove ucty. Kurzy to taha z CNB. Z excelu se bere zaklad a rozpoznava se co je asi co za operaci - vygeneruje se jiz rozumny cisty format dat do tabulek. Veci co jsou v PayPalu se transformuji do meho formatu automaticky. Pak se k tomu prirazuji platebni operace trocha ve stylu umele inteligence (umi to automaticky rozpoznat platbu za vice faktur, konverze men, prevody mezi ucty, poplatky atd). Mam tam par pomocnych tabulek, kterymi resim vyjimky/override pokud je treba nekde pouzit jiny kurz, nebo si nekdo splete castku/identifikaci platby, pripadne kdyz chci presunout vraceni dph az do dalsiho mesice. Taky to vede mzdy - pocita spravne odvody na zaklade zadane castky. Posledni ze skriptu projizdi vsechny ucetni pripady a generuje informace o zisku/ztrate/pohledavkach/zavazcich.

Z tohoto se jednou mesicne vygeneruje XML pro podani typu DP3,KH1,SHV - po nekolika mesicich jsem prisel i na to jak se jednotlive veci maji zaokrouhlovat pro financak, a verifikace vystupu je uz bez chyby.

Rocni danove priznani vyplnuji rucne, ale podklady se generuji automaticky (rozvaha, VZZ - bohuzel pro kazdy rok je to ve formularich na EPO jinak), stejne tak souhrn dluzniku. Tyhle data mam k dispozici kdykoliv behem roku (a muzu si je vyjet pro jakykoliv den) coz je dobra motivace pripadne nastroj k tomu, ze je dobre se uz ozvat neplaticum.

Od doby co se podavaji veci elektronicky a generuje to stroj, osobni kontakt s financakem ustal. A i kdyby nejaky byl - tenhle system pracuje na zaklade pevnych pravidel a kazdy kousek dat ma svoje zduvodneni (podle jakeho pravidla se dostal tam kde je). Pokud nekdo prijde s tim ze se to ma delat jinak - milerad system upravim. Zde se musim ucetnim co tvrdi "ale to nemuze delat stroj! prece kazdy pripad je jiny!". Veliky prd, musi to mit logiku, i kdyz ta je v tomto asi uz nad moznosti chapani danych ucetnich.

Jedina vec ktera me zatim stve je, ze celni urad neposkytuje JSD v elektronicke forme automaticky (rozumej: kdyz na nase EORI je vytvoren doklad, nemam o tom ani tuseni - pritom poslat to pres datovku nebo mejlem by nemel byt problem, predpokladam ze data nemaji jen na papire). Takze tyhle doklady musim prepisovat rucne.

Vim, ze tento system neni ucetne spravny - nemam sajnu o kodech uctu - ale mam svoji vlastni kategorizaci vsech operaci. Prinejhorsim to pujde namapovat pokud se bude chtit, protoze dat je tam vice nez je potreba a snazil jsem se o co nejuplnejsi reseni kvuli vlastnimu prehledu ve firme - takze mam k tomu i webove rozhrani s moznosti si projizdet data podle kategorizace pripadne subjektu, plateb, datumu. Puvodni pozadavek byl ale jen - dodat ta spravna cisla a neplatit si tupou opici jejiz praci nahradi stroj.

Prepocet 4000 pripadu za 5 let trva cca 90sec, db ma ~120K polozek.

Planuji dodelat sklad a nejake ERP (navrhujeme elektroniku.. tak je fajn kdyz to umi spocitat co osazena deska bude stat - pro jakekoliv mnozstvi, pripadne me to rekne co se ma nakoupit a co za soucatky jiz mame.. jedna se neco pres 1000 druhu komponent).

Vlastne zamereni na ERP jsem studoval na stazi v Nizozemi, takze se toho nebojim - nyni zcela chapu jak ma kazda firma jine pozadavky a proc stoji SAP tolik co stoji :)

Si rikam, ze az me prestane bavit hardware, mohl bych tohle rozjet jako sluzbu.

2002
Server / Re:ZFS deduplikace a spotřeba paměti
« kdy: 29. 11. 2017, 00:13:43 »
Maily maji mozna stejny obsah ale hlavicky jine a ty jsou na zacatku. Bohuzel v promenlive delce a uvazovat o deduplikaci je proto cisty nesmysl. Nekdy by to chtelo premyslet a znat trocha tu strukturu dat. Vzhledem k tomu ze jak ascii tak base64 by slo komprimovat dobre, tak pouzivej jenom on the fly kompresi (napr. zmineny ReiserFS). A dnes je taky misto docela levne - co vam brani si sestavit N*10TB pole? Jiste to bude levnejsi nez N*10GB ram :)

2003
Vývoj / Re:Jak se neztratit ve vlastním kódu?
« kdy: 22. 11. 2017, 21:39:47 »
Jak klasifikujes "vetsi projekt" ? Ve svych neco pres 600k LoC se porad dokazi orientovat (one man show), staci to pojmenovavat logicky a nemusim veci pak hledat - vzdy vim kde by co mohlo byt.

Pokud jsi ale neporadny sam, tak ti zadny tool nepomuze.

2004
Hardware / Re:Nestandardní rozměry displaye nb
« kdy: 19. 11. 2017, 11:11:48 »
Google Pixel ma 2560x1700, coz vasim 3:2 odpovida temer presne (2550x1700 + 5px vlevo a vpravo)

2005
Hlavni podminku co osvc nikdy nesplni je - byt k dispozici a umet vse. Pokud zakaznik za sluzby plati 240, tak je to mimo jine proto, ze ten dodavatel to ma a kdyz se toho chce vice, tak toho ma i vice. Ten "nepotrebny" prostrednik ma tedy na starosti nejenom zajisteni zakazek, ale taky pracovniku. Jako zakaznika ktery ma penize me nezajima hledani vhodnych lidi (osvc) na vyreseni nejakych problemu, zavolam korporatu a ten to za me vyresi rovnou. V tom je ta sila sluzeb a outsourcingu. Vetsina OSVC si na tohle outsourcovani pro velky jenom hraje, pac klasicka odpoved - nemam cas, neumim to - opravdu do tech vztahu nepatri.

2006
Vývoj / Re:Identifikace souboru
« kdy: 13. 11. 2017, 15:00:48 »
By me zajimal duvod / aplikace do ktere to tazatel potrebuje. To je tak tezke vyklopit co delate? Jiste se najde lepsi reseni nez tohle strileni naslepo.

2007
Server / Re:Extrakce mailu z provozu nebo pcap
« kdy: 13. 11. 2017, 13:48:50 »
Tak si nastudujte IP, TCP a SMTP, pak vam postaci hexdump z provozu :) Opravdu neni tezke si vyparsovat kazde spojeni a jako bonus nebudete mit zavislost na nejakem cizim toolu.

2009
Vývoj / Re:Použití GPIO jako input a output zároveň
« kdy: 09. 11. 2017, 14:34:42 »
Já ten obousměrný GPIO řešil v jednom zařízení skrze weak driver (diskrétně) - což je vlastně programovatelný pull rezistor - řiditelný mezi pullup nebo pulldown dle přání softu. Zároveň lze z portu číst reálný vstup. Prakticky musí být ale protistrana vůči tomu uzpůsobená - směr vstup funguje jenom pro inverzní hodnoty k směru výstup (použití: start/stop tlačítko s indikací stavu, skrze jeden drát).

Mělo by to zvládat úplně stejně např. XMEGA, který má kromě pullup i možnost nastavit pulldown. Klasické ATMEGA měli jen pullup.

2010
Prakticky nemuzete zapisovat na flashku rychleji nez vam dovoli, takze zda to bude 1 MB/s nebo 100 MB/s vam flashka urci.

Co se tyce prace se souborovym systemem - setrnejsi bude stahovany soubor presouvat az po kompletaci.

Jednak lze vyuziy prealokace datovych bloku a indexy se upravi jen jednou (man fallocate). Prubezne stahovany a zapisovany soubor totiz bude neustale upravovat indexy (zejmena informaci o aktualni velikosti). A treti aspekt je, ze cim pomalejsi zapis bude, tim vickrat se synchronizuje zurnal - hledejte commit v man mount.

Co se spotreby tyce - pouziti vyssi rychlosti je taky efektivnejsi (a po skonceni muzete flashku odpojit).

Stran: 1 ... 132 133 [134] 135 136 ... 153