Účtujeme v Linuxu a FlexiBee III. – faktury (diskuse)

[martin]

dotaz k vydaným fakturám - umí ten software: 1. fakturovat v cizích měnách 2. reverse-charge 3. vystavovat faktury v cizích jazycích (různé tiskové šablony) díky za info

[hw]

1. ano, 2. ano, 3. ano

[martin]

a jeste jsem zapomnel na jeden dotaz - umi u faktur s reverse-charge vystavit souhrnne hlaseni DPH?

[hw]

ano

[Luboš Doležel (Doli)]

Google dnes nejede? Měl by umět všechno.

[Dušan Hokův]

Tohle je fajn. Mytus o neexistujicim kvalitnim ucetnictvi v Linuxu je zboren.

[kaja gottzilla]

az na tu javu :(

[Luk]

Proč?

[Petr Ježek]

Ona java špatně účtuje? Chtělo by to argumenty...

[xea]

Kdysi jsem to zkoušel, je to děsivě pomalé, ukazoval jsem to účetnímu, vyhodil mě s tím, radši dál jede v účto v pcfandu (tuším kdysi tichý ježek).

[Luk]

No upřímně, oproti DOSové aplikaci (resp. obecně konzolové) je pomalé všechno. O neochotě účetních přecházet z takových programů (stále velmi zhusta používaných) na novější vím své, ale často je to jen věc zvyku. FlexiBee startuje dost pomalu, to je pravda, ale běžná práce už je v pohodě (pokud to někdo nezkouší spouštět na 10 let starém stroji).

[Luboš Doležel (Doli)]

Je fakt, že bych se nezlobil, kdyby to žralo méně. Tím myslím klienta, na serveru je mi to celkem fuk.

Druhá věc je samotné Swing GUI. Vidím dva problémy:

• Pokud použiju jiný vzhled než Metal, tak v textových polích není na výšku vidět celý text, protože dekorace si uřízly místo.
• Občas se mi stane, že otevřu dialog a ačkoliv jsou textová pole aktivní, nejde do nich psát, ani umístit kurzor. Po opětovném otevření je to OK.

[Luk]

Je fakt, že bych se nezlobil, kdyby to žralo méně.

Nevím, proč je to tak rozežrané. Není to Javou jako takovou, je to věc jejího použití.

Pokud použiju jiný vzhled než Metal, tak v textových polích není na výšku vidět celý text, protože dekorace si uřízly místo.

To je záležitost řešení layoutu. Jenže je otázka (na kterou neznám odpověď), zda to není záměr, aby se dialogová okna moc nerozrůstala.

Občas se mi stane, že otevřu dialog a ačkoliv jsou textová pole aktivní, nejde do nich psát, ani umístit kurzor. Po opětovném otevření je to OK.

Evidentní chyba, kterou je potřeba nahlásit

[Ladicek]

Pokud použiju jiný vzhled než Metal, tak v textových polích není na výšku vidět celý text, protože dekorace si uřízly místo.

To je záležitost řešení layoutu. Jenže je otázka (na kterou neznám odpověď), zda to není záměr, aby se dialogová okna moc nerozrůstala.

Pokud vím, snažíme se, aby se okna vešla i na 800x600, ale nejsem si tím jistý (s GUI nemám nic společného, tak to berte s rezervou). Ovšem uříznutý horní a dolní okraj textů jsem pozoroval taky, takže mne příjemně překvapilo, že když jsem si pustil aplikaci na Javě 7, text byl v inputech na výšku vidět celý a layout se (skoro) nezměnil. Tak možná tudy

Občas se mi stane, že otevřu dialog a ačkoliv jsou textová pole aktivní, nejde do nich psát, ani umístit kurzor. Po opětovném otevření je to OK.

Evidentní chyba, kterou je potřeba nahlásit

To jsem ještě nikdy nepozoroval a nejsem si jistý, jak bychom to dokázali zreprodukovat. Je to vysloveně náhodné, nebo za nějakých opakujících se podmínek?

[Luboš Doležel (Doli)]

To jsem ještě nikdy nepozoroval a nejsem si jistý, jak bychom to dokázali zreprodukovat. Je to vysloveně náhodné, nebo za nějakých opakujících se podmínek?

Je to vysloveně náhodné. Ta pole nejsou disabled, ale nelze s nimi pracovat.

[Luk]

Možná je chyba v Javě, v konkrétní verzi.

[Ladicek]

Takhle se chovají dopočítávaná políčka – třeba sumy na položkovém dokladu (ale když je bezpoložkový, dají se normálně editovat). Nejsou disabled proto, aby se do nich dalo vlézt a hodnotu si zkopírovat, ale editovat je nejde. Možná to má s tímhle problémem něco společného, ale fakt nevím.

[bambas]

Jezis tyhle predsudky a blaboly, za to bych vzdycky prislusnemu cloveku useknul prst. Oproti DOSu to bude vzdycky pomale, navic srovnavate hrusky s jabkama. Navic proc vas ucetni vyhodil jiste nebylo kvuli tomu, ze je to pomale, ale ze se to jinak ovalda. A staryho psa novejm kouskum nenaucis. Navic to, ze java je pomala, dnes uz takmer neplati, preci jen udelali krok kupredu.

[Luk]

Navic to, ze java je pomala, dnes uz takmer neplati, preci jen udelali krok kupredu.

Ona už hodně dlouho pomalá není, problémy s pomalostí se týkají jen GUI. V mnohých případech může být Java i rychlejší než program napsaný v C, protože runtime optimalizace mohou výkon výrazně zvýšit (i když si nemohu nerýpnout, jak Oracle optimalizaci ve verzi 7 zmrvil).

[JanM]

Navic proc vas ucetni vyhodil jiste nebylo kvuli tomu, ze je to pomale, ale ze se to jinak ovalda. A staryho psa novejm kouskum nenaucis.

Na nové ovládání nadávají měsíc, pak si zvyknou - to problém není. Na pomalost nadávají půl roku, pak si taky zvyknou. Co na to produktivita práce, už zůstane problémem těch účetních.

Znám to ze SAPu, teď máme krásnější layouty, ale bohužel se kvůli nim zobrazuje menší množství textu. [ironie]Není to samozřejmě problém, stačí najet myší...[/ironie] Ale nevadí, přes support desk to určitě do půl roku vyřešíme

Co chci říci - právě u rutinní práce je velmi důležité, aby program práci usnadňoval. (FlexiBee neznám, tak nekomentuji.)

[Luboš Doležel (Doli)]

Napojoval jste někdo FlexiBee na Raiffeisenbank? Bez toho jejich windowsáckého eKomunikátoru se asi neobejdu, co?

[Luk]

Bohužel v "rajfce" konto nemám (kdysi dávno jsem míval u eBanky, ale to už je hodně vzdálená minulost).

[Luboš Doležel (Doli)]

Bohatě by mi stačilo, kdyby šlo přes inet bankovnictví RB nahrát dávku s příkazy (např. autorské honoráře), abych to nemusel přeťukávat. Bohužel se i do této operace musí zapojit ten jejich win32 zmetek

[Luk]

KB naštěstí tohle umí dobře. Uvítal bych i Přímý kanál (aby výpisy chodily rovnou do účetnictví a naopak příkazy rovnou do banky, bez meziuložení do souborů), ale ty tři stovky měsíčně jim za to nedám.