Příspěvky uživatele

Nedávno se tady objevila zmínka o možném aktivním využití automatických oprav. Tuto ideu realizuje nástroj z přílohy v podobě dynamické aktivace / deaktivace vybraných skupin speciálních znaků tak, že aktivované znaky lze z klávesnice vyvolat mnemotechnicky srozumitelnými klávesovým zkratkami. To umožňuje snadno vytvářet texty s takovými znaky, které lze následně kopírováním přenést dokonce i sem:
a₄.x⁴ + a₃.x³ + a₂.x² + a₁.x + a₀ ≥ 0
3 H₂SO₄ + Al₂O₃ ⇒ Al₂(SO₄)₃ + 3 H₂O
V přiloženém zipu je kromě sešitu AutoCorrect.xlsm i krátký text s popisem principu a dvěma obrázky, jak mám zařízený rychlý přístup ke všem doplňkům, které si podle potřeby volám. Mé doplňky vždy otevřou formulář s dialogem; zavření tohoto formuláře automaticky zavře i doplněk.

Sám vidíte, že vzorce mohou být dost košaté. Pokud byste chtěl prvek ze seznamu s konstantním pořadovým číslem, asi by vzorec ještě ušel, kdybyste měl na mysli proměnnou polohu prvku, tak do toho bych se vzorem asi nešel. To už je na můj vkus úloha pro uživatelskou funkci, napsanou ve VBA. Taková UDF by byla prostičká, akorát nevím, jestli vám řešení VBA vyhovuje.
UDF může vypadat např. takto:

Function Prvek(Kec As String, Sep As String, Poradi As Integer) As String
Dim Pole
Poradi = Poradi - 1
Pole = Split(Kec, Sep)
If IsArray(Pole) Then
If Poradi > UBound(Pole) Then Exit Function
Prvek = Pole(Poradi)
End If
End Function

Konečně jsem se dokopal k tomu, abych splnil, co jsem slíbil.

Tak to se musím omluvit. Při nedbalém nahlédnutí do dat jsem usoudil, že časové intervaly v jednotlivých řádcích se překrývají. Proto jsem postrádal váhy pro jednotlivá období. Teprve po upozornění jsem zjistil, že intervaly na sebe plynule navazují, jen jsou v čase řazeny od posledního k prvnímu.
V tom případě by s výpočtem neměl být problém, pokud váhu ceny v jednotlivých dnech lze zanedbat. Za trest a na omluvu ten výpočet udělám

Hav-Rane, jako účetní bych si asi na chleba nevydělal, ale mám za sebou vývoj dvou účetních systémů pro podniky zahraničního obchodu socialistické éry, na kterém jsem se intenzivně podílel. Myslím, že vím velmi dobře, o čem je řeč při přepočtech kurzů, kurzových rozdílech a "půlhaléřových" diferencích.
Přesto si nemyslím, že by nastavený režim "přesnost podle zobrazení", který nabídl elCHa, nebyl pro účtárnu použitelný. Jen se asi musí dát bacha, aby výpočty na víc desetinných míst probíhaly v buňkách s vhodným naformátováním. Alespoň tak tomu režimu rozumím. Zatím jsem testy v tom směru neprovedl, ale doufám, že se nemýlím.

To zadání je statistický blábol. Co to je "cena v období"? Jakou váhu má to období? Krátké období může mít se svou cenou vysokou váhu, protože jde o cenu velkého množství, Jiné, třebas dlouhé období může mít naopak malou váhu, protože reprezentuje cenu malého množství.
Na špatně položené otázky existují pouze špatné odpovědi!

Palooo, nic jste nepochopil, test na shodu vyžaduje rovnost. Pokud shoda neplatí, Excel hlásí chybu shody. Kecy o tom, že účetní potřebuje čísla jen na setiny, s tím nemají co dělat. Dokud ten rozdíl neuchápete, budete asi dál psát blbosti...

Nastavit přesnost podle zobrazení je vlastností pro celý sešit (naštěstí ne pro celý Excel, bohužel ne pro daný list). Máte pravdu v tom, že pro účetního je toto nastavení asi tím správným krokem. Jinak se proti němu některé manuály silně vymezují, protože může vést na nepřípustnou ztrátu informace. To se ale netýká účtárny. Proto to pokládám pro účtárnu za krok správným směrem. Musím se ale podívat, jak se takový sešit chová k číslům v neformátovaných buňkách...
Kvůli tomu ale neopustím myšlenku, že by tak základní funkce listu, jako je SUMA, neměla vykazovat vadu, která nedovoluje přímý test na shodu.

Omlouvám se za pozdní odpověď. Mezitím jsem došel k závěru, že když se těch jmen zbavit neumím, že je alespoň aktivně využiji. Jinak vaše odpověď je pro mne cenná. ListObject moc osahaný nemám a stále na něm objevuji další metody a vlastnsti, které postupně dostávám do hry. O tom, že ListObject má svůj Name, nepochybuji od začátku. Že by to bylo současně i povinné jméno ve Workbook.Names, přičemž by šlo vlastně o jméno z Worksheet.Names, o tom jsem neuvažoval. Takže dík za náměty pro přemýšlení i zkoušení...

Paní účetní mi kdysi z žertu předhodila černou můru každého účetního. Klasickou úlohou účtařské rumařiny je párování položek. Poté, co indikátory pospojují většinu položek má dáti / dal, zbyde téměř zákonitě nevonná káď s nespárovanými položkami. Je spousta neuhrazených pohledávek a proti nim jiná spousta neidentifikovaných plateb. A začne párování hodnotou, které zpravidla přinese svoje významné ovoce. To, co zbyde, zapáchá ještě o něco víc. A začnou se skládat položky, jestli náhodou nějaké dvě platby nepokryjí beze zbytku nějakou neuhrazenou pohledávku. Jak každý rychle pochopí, vzniknout mohou velmi různorodé a daleko složitější kombinace pohledávek a plateb k nim.
No a paní účetní mi tenkrát nadhodila, že by s tím měly "ty naše mašiny" něco udělat samy. Tenkrát jsme se tomu spolu zasmáli. Po letech mne ale napadlo, že vlastně šlo o slovo do pranice a že jsem od toho problému tenkrát dost zbaběle utekl. Jde v podstatě o výzvu. Pokud by někoho napadlo, jak věc zautomatizovat, jistě by účtaři zaplesali. Ty dvě kádě s pohledávkami a platbami by nám jistě rádi nachystali. Pokud bychom z nich dokázali tahat spárované kapříky k posouzení, byli bychom hrdiny. Čím složitější kapry bychom dokázali vytvářet, tím bychom byli víc ceněni. Zkuste něco vymyslet. Pokusím se přidat k vám!

Nakonec mne napadlo ten test zmenšit, takže sešit s ním snad už projde

Palooo, asi jste na ten problém ještě nenarazil, ale standardní funkce listu SUMA má skutečnou chybu při sčítání velkého množství čísel s desetinnou částí. Pokud nevěříte tomu, co píšu já, věřte aspoň tomu, co napsal elCHa!
Je mi ovšem záhadou, že se autoři Excelu s tím problémem nikdy nepopasovali. Sám jsem si o něj rozbil hubu (jak už jsem napsal), a za posledních deset let se ke mně volání o pomoc v daném směru dostalo cca pětkrát.
Včera večer jsem své testy zopakoval. Problém přetrvává i v E-2010. Mám k tomu naprosto průkazný materiál, který jsem chtěl sem poslat, ale sešit byl moc veliký a z neznámých důvodů mi neodešla ani příloha JPG s ukázkou chyb.
Co je ale nejpodstatnější, podařilo se mi napsat UDF, která je k chybě funkce SUMA imunní a počítá správně.
Funkce vypadá následovně:
Function CurSum(Oblast As Range) As Currency
Dim Pole As Variant, Soucet As Currency
Dim i As Long, j As Long
Application.Volatile
If Oblast.Areas.Count > 1 Then Exit Function
Pole = Oblast
For i = 1 To UBound(Pole, 1)
For j = 1 To UBound(Pole, 2)
Soucet = Soucet + Pole(i, j)
Next j
Next i
CurSum = Soucet
End Function
Připadne mi dost úsměvné, že jsem to dokázal naprosto standardním výpočtem. Když to šlo mně, proč to dávno Microsofti neopravili ???

To řešení funguje, ale nemá zpětnou vazbu. Dodatečná změna A1 po předchozím vyplnění A2 nebude přehodnocovat, jestli A2 vyhovuje i novému A1. Takovou silou technika ověření dat nedisponuje.
Hezky a podle mne správně se chová technika, kterou jsem tady na fóru nedávno zaregistroval: když se změní ověřovací podmínka, automaticky se smaže ověřená hodnota. K tomu je využita událost Worksheet.Change pro ověřovací oblast. Je to surové řešení, ale nedovolí, aby jako ověřená hodnota na listu figurovalo něco, co aktuální ověřovací podmínku nesplňuje.
Změkčit dopady tohoto postupu by mohlo vyhodnocení, jestli hodnota v A2 nadále splňuje novou ověřovací podmínku podle A1. To samozřejmě možné je, ale je otázkou, jestli se v tom ta původní ověřovací technika nezačíná ztrácet...

Začínat týden sobotou je poměrně zvláštní (hodnota 16 ve druhém parametru WEEKNUM). Ale proč ne! Zrada může být i jinde. Excel ve svém základním stavu nedodržuje evropskou normu pro stanovení začátku roku, což může vyvolat posun pro pořadové číslo týdne. Už si to dobře nepamatuji, ale V USA je snad prvním týdnem roku ten, kde se nachází 1.leden. V Evropě je první týden ten, ve kterém jsou alespoň 4 dny z nového roku. Poznatek, že vzorec hodnotu poskytuje, ale nesprávnou, může plynout i z odlišného vyhodnocení, co je první týden roku.

To naštve a chápu stav na mrtvici, který na Ala dolehl. Bohužel takovou věc čas od času potkáme všichni a jedinou pomocí bývá "vydržať", které si dobře pamatuji z jednoho z prvních slovenských TV seriálů. Držím palce!
Na odlehčení situace jedna ze života: kdysi jsem koupil od nějakého soukromého vynálezce jeho SW produkt. A neběhal. Po reklamační tahanici jsem se od autora dozvěděl, že produkt je zcela funkční, jen se okamžitě po startu automaticky a natrvalo zastaví...

Příspěvky uživatele

Uživatelské menu

Menu

Formulář Faktura

Formulář Faktura IV

Helios iNuvio

On-line nástroje