Příspěvky uživatele
< návrat zpět
Pokud rozumím, není třeba používat cyklus
Pro oba případy postačíDim vVals As Variant
vVals = Application.Transpose(Range("Zkratky").Value)
nebo jednodušeDim vVals As Variant
vVals = Range("Zkratky").Value
záleží jak chcete mít pole indexované
ehm
a jaký graf máte na mysli?
Nicméně - matematicky je podle mně správně pouze řešení vycházející z počtu dní, dávající výsledek, ze kterého jednoznačně počet dní zpětně zjistím - čímž se vracím k mému úvodnímu příspěvku). Takže např.:=USEKNOUT((DatumDo-DatumOd)/365,2425)&"R-"&USEKNOUT(MOD(DatumDo-DatumOd;365,2425)/365,2425*12)&"M-"&MOD(MOD((DatumDo-DatumOd);365,2425);365,2425/12)&"D"
29.12.2006 1.3.2014 7R-2M-1,42875D
Takže interval je 2619 dní
Zpětně tedy:
7*365,2425 = 2556,6975
2*365,2425/12 = 60,87375
1,42875
2556,6975 + 60,87375 + 1,42875 = 2619
Ale to jen pro zajímavost - o to tu nešlo - jen je tu po dlouhé době jiné a celkem zajímavé téma, díky němu jsem objevil (byla mi ukázána) a hned v podstatě zatratil fci DATEDIF ;))) - i když pro rozdíl měsíců asi použitelná bude ;), roky se dají zjistit snadno
29.12.2006 - 1.3.2014 - 7R-2M-3D - 7R-2M-1,42875D
30.12.2006 - 1.3.2014 - 7R-2M-2D - 7R-2M-0,42875D
31.12.2006 - 1.3.2014 - 7R-2M-1D - 7R-1M-29,865625D
3.2.2008 - 3.3.2012 - 4R-1M-0D - 4R-0M-29,03D
3.2.2008 - 3.3.2008 - 0R-1M-0D - 0R-0M-29D
3.2.2009 - 3.3.2009 - 0R-1M-0D - 0R-0M-28D
Inak, lubov vzorec je pmn už viacmenej stráviteľný, pokiaľ je jeden ochotný akceptovať, že dáva ten istý výsledok napr. pre nasledujúce kombinácie začiatku a konca:
29.12.2006 1.3.2014 7R-2M-1D
30.12.2006 1.3.2014 7R-2M-1D
31.12.2006 1.3.2014 7R-2M-1D
Mno ono je to sporné a je to o metodice. Jak je správné počítat dny? Podle mne je třeba dopočítat dny do konce měsíce v prvním datu a potom začít počítat dny měsíce ve druhém datu.
29.12.2006 1.3.2014 7R-2M-3D
30.12.2006 1.3.2014 7R-2M-2D
31.12.2006 1.3.2014 7R-2M-1D
29.12.2006 28.2.2014 7R-1M-30D
30.12.2006 28.2.2014 7R-1M-29D
31.12.2006 28.2.2014 7R-1M-28D
3.2.2008 3.3.2012 4R-1M-0D
3.2.2008 3.3.2008 0R-1M-0D
3.2.2009 3.3.2009 0R-1M-0D
Řešení mně napadlo hned, jak jsem včera vypnul počítač ;))
=DATEDIF(DatumOd;DatumDo;"y")&"R-"&DATEDIF(DatumOd;DatumDo;"ym")&"M-"&DATUM(ROK(DatumOd);MĚSÍC(DatumOd)+(DEN(DatumOd)>DEN(DatumDo));DEN(DatumDo))-DatumOd&"D"
@AL
ano, mám - jen je třeba doladit poslední položku (den)
bohužel zase musím běžet - takže mám rozpracováno toto=DATEDIF(DatumOd;DatumDo;"y")&"-"&DATEDIF(DatumOd;DatumDo;"ym")&"-"&DEN(DatumDo)-DEN(DatumOd)+(DEN(DatumOd)>DEN(DatumDo))*((DATUM(ROK(DNES());MĚSÍC(DatumOd)+1;1)-DATUM(ROK(DNES());MĚSÍC(DatumOd);1)))a na první pohled se to zdá v pořádku. Možná by mohl někdo hodit druhý pohled nebo tu část pro den zkusit zjednodušit ;))
Ještě jsem stihl druhý pohled a asi tam je ještě něco k doladění ;))
Prostě pro den použít něco jiného než DATEDIF a bude to ;)
@AL
tak už mám trochu času, a ten vzorec jsem si přeložil. Přiznám se že o DATEDIF jsem nevěděl, takže jsem zase o něco chytřejší. Tím pádem je moje řešení zbytečně složité a tedy Lenn stačí to Vaše ;)
Našel jsem si i ty parametry a chtěl navrhnout=DATEDIF(DatumOd;DatumDo;"y")&"-"&DATEDIF(DatumOd;DatumDo;"ym")&"-"&DATEDIF(DatumOd;DatumDo;"md")lubo mně předběhl ;))
pro 1. datum 31.12.2006 a druhé datum 3.3.2014 (zkouším potom co napsal lubo) Vám to ale vrací výsledek 7R-2M-0D, stejně tak jako moje úprava vrací 7-2-0
@lubo
je o tom problému někde více informací? Protože takhle to neukazuje pouze na argument "md".
Jen pro pořádek - opraveno, ať to počítá stejně ;)
@AL
všiml jsem si a také jsem editoval ;)))
btw - podle mé teorie z minulého příspěvku je 8R-7M-3D špatně a mělo by být 4D (takže u Vás počítáte oba případy stejnou metodikou, kdyžto já pokaždé jinak - takže to ještě teda opravím ;)) )
Ale to ať už si Lenn rozhodne sama - cestu jsme ji ukázali ;))
@AL - mno, že byste měli na Slovensku jiný počet prstů než my? 
Já bych to viděl na 7 - protože pokud je nástup 31., tak je to včetně, jinak by byl nástup 1.
A zase - dnešní den se počítá nebo ne - já ho počítám ;)
Takže na prstech 31 - 1 - 2 - 3 - 4 - 5 - 6
mně šlo ale hlavně o ty roky a měsíce - bylo to v rychlosti a nechce se mi to už zkoumat - tam sedíme, tak je to ok ;)
edit po Vašem editu ;)):
nene - UDF ne
musel byste uložit s podporou maker, povolovat makra atp.
to raději ta obludnost nebo přes více buněk jako já (což bych asi preferoval já - snadnější opravy)
@AL Nástup 31.12.2006 => 7 let, 10 měsíců a 7 dní
Jen pro kontrolu, jestli to mám ještě zkoumat ;)))
AL napsal/a:
S istým zjednodušením by sa dal asi použiť trochu hrôzostrašný vzorec :
Nechce se mi to předělávat do češtiny - kolik Vám to hodilo výsledek? ;))
Pokud je znám datum nástupu, pak bych to udělal takto - viz příloha.
Dělal jsem to 10 minut - nemám teď moc času, takže je to třeba otestovat
Podle toho mi to vyšlo 8 let, 7 měsíců a 3 dni ;))
Mno - to je zajímavá otázka a jsem zvědavý na další odpovědi. Ale tipl bych, že přesně to nelze. Pokud máte číslo 8,59, je jasné, že je to 8 roků.
A dál? Budeme brát rok jako 365,25 dní? Kolik bylo v tom období přestupných roků?
Kolik dní má měsíc? Pokud bychom brali, že rok má 365,25 dní a 12 měsíců, pak má měsíc 30,4375 dne?
Takže 8 roků
0,59 * 365,25 = 215,4975 dní / 30,4375 = 7 měsíců a zbývá mi 2,435 dne.
Takže já jsem se dostal na 8 roků, 7 měsíců a 2 dny.
Když to spočítá někdo jiný, dostane se blízko, ale ne stejně ;))
Pokud to chcete přesně, asi potřebujete datum nástupu ;)
Ale to je můj názor - třeba má někdo lepší - je to o matematice, ne excelu ;))
edit: když bude mít rok 365,2425 dne (v gregoriánském kalendáři) bude výsledek jiný ;)
Mno, asi takhle.
Každý zápis do logu spustí překalkulování souboru. Každá úprava hodnoty spustí opět překalkulování. Pokud tam máte 5 vzorců, tak to nevadí - ale pokud jich tam budou tisíce, bude to znát. Každý zápis do logu zvyšuje velikost souboru. Toto jsou některé důvody, proč to řeším přes textový soubor.
Pokud jde o to, že stačí odkliknout vlastnosti - to je jasné, ale předpokládám, že toto uživatelé záměrně dělat nebudou. Nepodceňujte je, ale ani nepřeceňujte. Proč by to dělali. Přínos bude v tom, že sešit bude jen pro čtení a při pokusu o uložení ho to upozorní a se ho to zeptá na nový název. Totéž, pokud to provedete přes zaheslování úprav. Tady se mi ale občas stane, že o tu vlastnost přijde a musím zaheslovat znovu.
Pokud to budete sledovat kódem - je úplně stejně snadné řešení jak to obejít a nemusím ani mazat log, jak psal AL. Prostě zastavím sledování událostí. Jeden příkaz a nemusí být ani úmyslný, stačí chyba někde v kódu.
A teď se Vás zeptám - pokud jsem Vám opravoval kód v minulém vlákně, myslíte, že budete schopen uhlídat spíše verzi pro čtení (protože zcela určitě budete mít zálohu a budete si ukládat i starší verze, pokud by v té nové něco nefungovalo správně a v případě potřeby "pokažený" soubor nahradíte správným) nebo verzi řešenou kódem. Neberte to osobně, každý jednou začínal - já mám soubor vytvářený a laděný 10 let a i tak se tam někdy objeví nějaká chyba, která mi zastaví události.
Btw - pokud chcete zjistit, kdo soubor pokazil - kliknete pravým tlačítkem a kouknete na vlastnosti = "Naposledy uložil"
Předpokládám, že se jedná o pokračování minulého dotazu.
Pořád platí - uložte sešit jako šablonu.
Pokud nevyhovuje - uložte sešit pouze pro čtení (jakýmkoliv způsobem) a nemusíte se bát a vymýšlet komplikovanosti
Uživatelské menu
\nMenu
Formulář Faktura
Formulář Faktura IV
Oblíbený formulář Faktura byl vylepšen a rozšířen.
Více se dočtete zde.
Helios iNuvio
Používáte podnikový systém Helios iNuvio? Potřebujete pomoci se správou nebo vyvinout SQL proceduru? Více informací naleznete na stránce Helios iNuvio.
RSS nejnovější články