Fórum pro uživatele kancelářského balíku OpenOffice | LibreOffice
 

#1 4. 2. 2016 14:44:46

hdplot
Člen
Registrace: 18. 2. 2015
Příspěvků: 79

Sumární součet dvou různých tabulek - VYŘEŠENO

Opět se na vás obracím s prosbou o radu.

Mám 2 tabulky - "Pokladna" a "Banka", které obsahují obdobné sloupce. Pro moji otázku je důležité, že obě tabulky obsahují sloupec "Castka" Nad každou tabulkou lze vytvořit dotaz, který sloupec částka sečte a tím zjistím aktuální hotovost v bance nebo v pokladně samostatně. Dá se ale vytvořit dotaz, který sečte dohromady obě tabulky, nebo druhá varianta - dotaz, který sečte dva předchozí součtové dotazy jednotlivých tabulek ?

P.S. Nakonec jsem to vyřešil takto -  obě tabulky jsem sloučil do jedné, rozlišil je příznakem (další sloupec ve sloučené tabulce) a pak dělám součet celé tabulky, nebo součet filtru podle příznaku. Ale obecně dotaz zůstává v platnosti (může se hodit v budoucnu)

Díky za odpověď

Editoval hdplot (5. 2. 2016 15:36:20)

Offline

#2 4. 2. 2016 18:08:48

neutr
Člen
Registrace: 8. 3. 2007
Příspěvků: 2,678

Re: Sumární součet dvou různých tabulek - VYŘEŠENO

Je to zřejmě důležité téma pro reálné využívání Base. Proto uvedu možnosti řešení.


To nejméně efektivní, ale spolehlivé řešení je vytvořit pohled - například když byste dělal relační databázi (ale může být i vícesloupcová - nerelační).
     Pohled dělá "variace bez opakování". Je to jako "tachometr". Například sloupec první tabulky (=A) - bude mít 50 záznamů. Sloupec druhé tabulky (=B) bude mít 20 záznamů. Pohled vygeneruje 1000 položek. Každé položce A přiřadí každou položku B.
     Nad tímto pohledem vytvoříte formulář s dotazem, nebo jen dotaz. Pak jde o to co budete chtít dělat dál. Pokud budete chtít jenom sečíst příslušné položky z jednoho typu sloupce bude postup jiný, nežli v případě že chcete dělat rozdíly (to co uvádíte v dotazu). Když se to řeší tak pomocí aliasu v dotazu. Tam se načtou podle vzorce hodnoty jako + a -. Součet ze sloupce aliasu je to co hledáte.
     Řešení může být i pomocí filtru, ale filtr funguje ve formuláři špatně. Lze zadat jen jedno filtrované pole. Takže ne všechny potřeby se dají dělat jen filtrem (bez aliasu). Zase když by se zaváděly originálně například výdaje mínusem a příjmy plusem tak filtr stačí - odfiltruje položky bez potřebného příznaku a sloupec se sečte..
     Tenhle postup ve spojení s "pohledem" umožňuje například komplexní vyhodnocení všech položek (má dáti - dal). Jinak je to ale poměrně zbytečně složité. Vždy musíte vytvořit pohled znovu a ten aktuální by se měl vždy jmenovat stejně. To znamená buď původní pohled smazat, nebo přejmenovat. nevýhodou je také ta "variace". Když byste vytvořil v prosinci pohled za celý rok může to být tak velké, že to stroj neuveze.


     Problém je prakticky jen v jediné věci. Najít společný jmenovatel pro obě tabulky a pak se dají dělat všechny možné opičárny. Například u výpisů z banky je to snadné - bude tam nějaký variabilní, nebo jinak podobný symbol. Pak stačí udělat vazby. Z nich následně dotazy a formulář být ani nemusí. Stačí sestava pro tisk. Toto řešení ať už s formulářem, nebo bez něj je nejlepší, ale musíte dostat dva součty - někam a udělat vyhodnocení - nejspíš součet dvou součtů sloupců ve formuláři. To bych viděl nejlépe jako dva SubFormy v MainFormu, ale jde to také sečíst například makrem.
     Jde také přímo postavit jen dotaz - zejména SQL a vracet položky po součtu. Tohle by mělo jít i bez "vazeb" mezi tabulkami. Vyjde to ale "nastejno". Spíš půjde o erudici při psaní SQL dotazů.
     Bohu žel asi ne vždy najdeme ten "společný jmenovatel", respektive mohou existovat naprosto různé potřeby. Například dohledat chybně vypsaný variabilní symbol, nebo otestovat platby v určitém období a zkoušet komparace na určitou výši.


     Takže pak by asi řešením bylo manuální procházení databází a přepis položek do nové databáze. Tohle se může stávat zejména při vzájemných zápočtech a "bez rozumné" systematiky, nebo při vysloveně špatném vyrovnávání závazků "protislužbami", respektive nefinančním plnění (zřejmě podstata Vašeho problému v nekoncepčnosti pokladna - banka). To by měly být správně podle účetní osnovy zakázané operace - jenže účetní může skákat 3 metry vysoko. Když je možnost směnného obchodu - kdo by chtěl počítat a odevzdat daň? Tak se zavede do účetnictví nějaká kravina - vždyť nula od nuly pojde. Ne dělám si legraci - od výdajového dokladu k zúčtovatelné položce je daleko a cesta je nevyzpytatelně různorodá. Lituju účetního který dostane krabici papírů a má dělat daně :-(
     Takže řešením je vlastně vytvořit nějaký sekundární klíč pokud se nenabízí podobný VS ap. To může být případ pokladny odkud se dávají "zálohy" a podobné věci. Naklíčovat výdejní a příjmové doklady pokladny + normální fakturaci je jistě obecný problém. Profi programy to mívají ošetřeno, ale ani tak se průšvihu nezabrání.


     Vycházím z toho, že ten kdo staví účetní systém v Base nepoužívá standardní komerční program, nebo potřebuje výstupy z více různých programů sjednotit. Takže jde o to správně nastavit vstupy a výstupy, tabulky a jejich struktury. Z toho pak musí vycházet vazby a standardní dotazy bez zbytečných operací a průzkumů. Teprve následně mohou být vytvořeny formuláře které budou dělat co je potřeba a vystačí si s omezenými možnostmi Base.
     Base je sice omezená, ale tím že spolupracuje s Calcem tak se vyrovná i těm nejlepším databázovým systémům ať jsou pojmenované jakkoliv. Takže já osobně upřednostňuji práci přímo a jen v Calcu. Když potřebují něco udělat aby to vypadalo lépe nežli rozhraní tabulkového procesoru, tak to vytvořím v Calcu jako CSV a na to udělám formulář. Pak jde jen o to aby se CSV dalo Calcem předělávat. To souvisí s registrací databáze, ale i Calc může být jako databáze registrován.
     Takže to je moje rada : - Problematické operace dělejte v Calcu. Jde to Basí "překrýt" že to nikdo nevidí. Base se musí sice aktualizovat (opětovně načítat), ale tak velký problém to není. Calc může být spuštěn jako "hidden" a nahrazovat nedostatky SQL (největší omezení Base) více nežli dobře.


     Zřejmě zajímavé (zejména nyní - když jsou žně účetních) je zpracovávat Calcem vstupy, vyplivnout je v požadovaném rozvržení klientského účetního programu a vytvořit daňové přiznání - respektive podklady pro odsouhlasení.
     Nejzajímavější je možnost naskenovat doklady pomocí OCR, následně načíst Calcem a dokonce to i automaticky spočítat - vytvořit deník ap. všechny agendy.
     Největší problém je s kontrolou OCR, ale vyplatí se to. Novější OCR umí pracovat se šablonami, takže po prvních ukoptěných pracích a opravách lze získat vzory nejčastějších, nebo všech příjmových a výdajových dokladů. Krabice se seřadí podle data a naskenuje se (může i naprostý laik). Provede se OCR a někdo fundovaný to zkontroluje ve smyslu správnosti rozpoznání obsahu a ve smyslu seřazení podle data (vše v OCR). Následně se udělá výstup do formátu csv, nebo Excelu. O zbytek už se mohou postarat makra. Výstupy mohou být například jako dBase, nebo CSV (podle toho jaký účetní program finální klient užívá - musí to být program uznávaný - problémy jsou s legislativou). Takové podklady se načtou jako záloha. Po pře chroupání profesionálním programem který by měl vyplivnout případné chyby a nedostatky) je hotovo. Účetní na tom nemusí ani moc dlouho pracovat - hlavně jen ze začátku. Profesionální účetní program ani vlastnit nemusí, ale měl by mít k němu přístup kvůli kontrole. OCR bývá ve výbavě tiskáren i když někdy dost omezený, ale profi program (Recognita, Finereader ap.) jsou v řádech několika tisíc.

Editoval neutr (4. 2. 2016 18:10:18)


Pokud je Váš problém vyřešen, označte prosím svůj příspěvek za "VYŘEŠENÝ"
Zlepšíte tak orientaci na fóru při vyhledávání řešení problémů
JAK OZNAČIT TÉMA ZA VYŘEŠENÉ

Offline

#3 5. 2. 2016 15:35:27

hdplot
Člen
Registrace: 18. 2. 2015
Příspěvků: 79

Re: Sumární součet dvou různých tabulek - VYŘEŠENO

Odpověď více jak vyčerpávající. Problém je již vyřešen (sloučením tabulek, jak jsem psal) ale odpověď dává další varianty a řeší problém do mnohem větší hloubky, než jsem potřeboval. Takže to bude zdroj informací i do budoucna ...


Díky

Offline

Zápatí