AyMINE – Technická dok. (anglicky)
Obchodní procesy
Nabídky a zákaznické objednávky
Správa ceníků
Zákaznická podpora
Řízení projektů
Plánování a řízení projektu
Řízení požadavků a testy
Komunikace a sdílení informací
Vnitrofiremní procesy
Kvalita a spolehlivost
Systém řízení kvality
- Stanovení odpovědnosti za úkol v metodice
- Metodika v systému řízení kvality
- Směrnice a politiky
- Přehled povinností stanovených metodikami nebo předpisy
- Pojmy
- Vzor protokolu / záznamu
- Vzorový úkol – Pracovní postup
- Objekty vztahující se ke vzorovému úkolu
- Řízení posloupnosti úkolů
- Součástí systému řízení kvality
- Zahajující události
- Aktivace události z úkolu
- Vzorové riziko
- tskdefusertask_raisingevents
Projektová metodika
Metriky a hodnocení
Správa majetku
- Produkty, aktiva, nákup a prodej
- Analytický model
- Dodavatel produktu
- Kategorie produktů
- Vlastnost produktu nebo výrobku
- Cíl projektu
- Přehledy nabídek
- Přepočítat nabídku a objednávku
- Přehledy objednávek
- Produkty a zboží
- Stav produktu a jeho změna
- Původ produktu
- Kritéria kvality
- O kritériích kvality u produktů
- Lokalita
Personalistika
- Bezpečnost modulu personalistiky
- Modul Personalistika
- Personalistika – uživatelská oprávnění
- Evidence uchazečů o práci
- Správa údajů o oddělní / divizi
- Změna vedoucího oddělení
- Pracovní pozice
- Pracovník
- Přehled vlastních pracovníků
- Odpovědný personalista
- Synchronizace pracovníků a uživatelů systému
- Pracovní smlouva
- chartsstaffer
- Modul personalistika | Systémové role
- Kvalifikace, schopnost / dovednost
- GDPR a evidence kvalifikací
- Právo spravovat kvalifikace uživatelů
- Kvalifikace uživatele, pracovníka nebo kontaktu
- Právo spravovat kvalifikace uživatelů
- Kvalifikace uživatele nebo kontaktu
- Evidence úrovní zkušenosí
Technická podpora – helpdesk
CRM & Správa kontaktů
- Adresář obchodních kontakt
- Kontakt v adresáři
- AyMINE modul CRM - uživatelská dokumentace
- Přehled zákaznických objednávek
- Seznam a správa adresářů
- Ochrana osobních a obchodních údajů
- Šablona zprávy
- Skupiny kontaktů
- Přehled objednávek pro zákaznické skupiny
- Kontakt na osobu nebo firmu
- Rychle dostupné kontakty
- Statistiky e-mailů
Správa Web portálů (CMS)
- Správa a automatizace webu
- Blok webové stránky
- Bloky na webové stránce
- Skript generující stránku
- Příjem zprávy z webu
- Odpovídací formulář – nastavení
- Popis webové stránky
- Web se speciálními potřebami
- Web portál
- CMS pro velký web
- Nastavení základních web služeb
- Uložit přístup k webové stránce
- Konektor pro webové služby
Systémové moduly
Úvod do AyMINE
- Rozšíření objektů
- introhelp_generalinfo
- introhelp_settings
- Zásady uchovávání hesel
- introhelp_shortcuts
- Systémová oprávnění
- introhelp_settings_dnadrhal9000_mar-22-220236-2023_caseconfl
- Moduly AyMINE
- Úvod do systému AyMINE
- Uživatelské zámky
- introhelp_privateobjectnotes
- introhelp_keyshortcuts
- Framework – systémový základ pro SaaS
Správa systému
Přizpůsobení potřebám firmy
Multitenant administrace
Rozhraní na jiné systémy
Konektor na ERP Abra Gen
Sabre: webDav, calDav
Konektor na Enterprise Architect
Formátované texty v aplikaci
Aplikace podporuje různé interní formáty a v některých případech dává na výběr, který zvolit.
V kostce: Markdown nebo HTML?
Pokud nepotřebujete styly a barvy písma, je Markdown vhodnější. Pokud se ale bez barviček neobejdete, nezbude, než zvolit HTML.
Je na výběr
Aplikace většinou na výběr nedává – různé formáty by vytvořily zmatek, který by převážil nad výhodami. Standardně je všude používán Markdown, i když s řadou rozšíření.
Aktuálně je HTML formát používán standardně pouze pro emaily a šablony emailových zpráv. HTML je pro email standard a jeho převod do markdownu není prakticky použitelný.
Volitelně je možné HTML využít i pro psaní informací. Další objekty s HTML mohou definovat moduly.
Markdown a jeho vlastnosti
Markdown je standardní formát, jeho struktura je jednodušší a neobsahuje tzv. párové značky. Díky tomu nehrozí, že se rozpadne jeho struktura, jak se to snadno stane u HTML, když do něj zabloudí např. nějaké <div> navíc.
Výhody markdown
Je řada dobrých důvodů, proč považujeme markdown za vhodnější:
- Automatické překlady – posílat do překladačů HTML je i pro překladač, který se HTML strukturu snaží udržet, výrazně náročnější. Výsledek není vždy v pořádku, někdy si s HMLT překladače neporadí vůbec
- Barvy – Systém umožňuje používat světlé i tmavé pozadí, ale pokud by uživatelé nastavovali textům interní barvy, je inverzní zobrazování velmi problematické. Problémy jistě zná každý, kdo chce používat email v tmavém prostředí.
- Zobrazení začátku textu – Z markdown dokumentu je velmi snadné zobrazit začátek dokumentu, např. první odstavce. S HTML toto obecně bez načtení celého dokumentu není možné.
- Zaškrtávací pole a jejich kontrola – Markdown od základu podporuje checklisty, tedy seznam se zaškrtávacími poli. Ty je samozřejmě možné vytvořit i v HTML, ale jejich používání a prohledávání v markdown je výrazně jednodušší. Systém automticky kontroluje, kde nejsou zaškrtnuty např. kontroly u úkolů a pohodlné vyplňování. Pro to je markdown přímo dělaný.
- Automatické formátování – díky tomu, že markdown neobsahuje formátování v dokumentu, je snazší ho zobrazit tak, jak se hodí vzhledem k obrazovce a způsobu použití.
- Kombinace různých obsahů – spojit více markdown dokumentů je výrazně jednodušší, nehrozí problémy s různými styly.
Není všechno čisté
Markdown ve své čisté podobě bohužel neumožňuje např. vložení obrázků nebo tabulky. Aplikace proto využívá rozšířenou syntaxi, která tyto reálně nezbytné možnosti doplňuje.
HTML a proč má někdy navrch
Pokud potřebujete detailnější formátování nebo uložit vstup z internetu, bude "tzv. ruční formátování" vhodnější.
Ručně formátovaný text je uložen ve formátu HTML, používá jiný editor, který dává další možnosti:
- Zarovnávat text
- Lépe pracovat s tabulkami a bloky
- Používat barvy písem
- Používat fonty
Rizika a nevýhody HTML
HTML má nevýhody, kvůli kterým standardně není používán. Je dobré na ně pamatovat. Nepřekvapivě jde o hlavní výhody markdown, jak jsou uvedeny výše.
Barvy písma
Jak už je uvedeno výše, barvy písma jsou fajn, ale jenom do té doby, dokud si text zobrazují všichni za stejných podmínek. Nezapomeňte ale, že polovina lidí používá světlé pozadí a polovina tmavé. Když nějakému textu dáte červenou nebo jasně modrou barvu, tak je v pořádku. Ale když vnutíte např. černou nebo naopak světle šedou resp. jakoukoli barvu na okraji jasných a tmavých, polovina čtenářů s tím bude mít problém.
Poznámka: Důvod nepoužívání barev je zcela zásadní pro jejich nepoužívání např. v požadavcích. Hrozí velké riziko, že si řešitel nemusí části textu všimnout. Proto aplikace používání barev v požadavcích nepodporuje.
Styl písma (font)
Styly písma (fonty) pomáhají zvýraznit některé pasáže, ale stejně jako u barev platí, že co vidíte vy, nemusí vidět čtenář. Např. maily fonty nepoužívají, resp. většina prohlížečů je standardně nepoužívá. Styly v emailu by se proto neměly používat vůbec.
Styly se nepřenesou ani do generovaných PDF dokumentů; generátor má vlastní sady písem. Proto zvýraznění, které máte na obrazovce, bude v dokumentu vypadat jinak.
Styly nemusí mít ani čtenář, který informaci dostane – jeho prohlížeč písma nemusí stahovat; např. na mobilních telefonech je to časté.