↓

Úprava a vývoj POHODA na mieru: od nastavenia po vlastný modul

Vývoj POHODA nemusí znamenať zásah do jadra programu. Väčšinu potrieb pokryje nastavenie, hotové rozšírenia a prepojenie cez XML rozhranie; vlastný vývoj patrí tam, kde štandard naozaj nestačí.

Aktualizované 28. októbra 2026

Keď firma hovorí o vývoji POHODA, zvyčajne tým myslí jednu z dvoch vecí: chce, aby program robil niečo, čo robí inak, alebo chce, aby sa „rozprával“ s e-shopom, skladom či pokladnicou. Obe potreby sa dajú vyriešiť, no s veľmi odlišným rizikom. Táto stránka ukazuje, ako rozlíšiť nastavenie, rozšírenie a skutočný vývoj, čo to znamená pre aktualizácie a podľa čoho vybrať človeka, ktorý to urobí.

Personalizácia POHODA: tri úrovne, od najlacnejšej po najnáročnejšiu

Pri personalizácii POHODA platí jednoduché pravidlo: zostať čo najbližšie k štandardu. Každá ďalšia úroveň zvyšuje cenu práce aj závislosť na konkrétnom človeku.

Úroveň Čo to je Vplyv na aktualizácie Kto to zvládne
Nastavenie Číselné rady, tlačové zostavy, používateľské práva, predvolené hodnoty, šablóny dokladov Žiadny, nastavenie je súčasť programu Pokročilý používateľ, účtovník, školený konzultant
Prepojenie cez rozhranie Výmena údajov so skladom, e-shopom alebo pokladnicou cez XML Nízky, ak sa používa podporované rozhranie Vývojár alebo intégrator s praxou v POHODE
Vlastný vývoj Samostatná aplikácia alebo modul, ktorý rieši proces mimo štandardu Stredný, treba test po každej zmene verzie Vývojár s dokumentáciou a dohodnutou správou

Väčšina malých a stredných podnikov na Slovensku vyrieši potreby prvými dvoma úrovňami. Tretia sa oplatí až vtedy, keď ide o proces, ktorý je skutočnou konkurenčnou výhodou, nie o pohodlie.

Čo sa dá nastaviť bez programovania

Skôr než sa objedná akýkoľvek vývoj, prejdite to, čo program ponúka sám. Prekvapivo veľa „chýbajúcich funkcií“ je v skutočnosti len nenastavených.

  • Doklady a tlačové zostavy. Vzhľad faktúr, ponúk a objednávok sa zvyčajne upravuje bez zásahu do funkčnosti programu.
  • Číselné rady a predvolené hodnoty. Každý typ dokladu, stredisko či zákazka môže mať vlastné pravidlá.
  • Práva používateľov. Obchodník nemusí vidieť mzdy a skladník nemusí vidieť ceny nákupu.
  • Používateľské filtre a prehľady. Výstupy pre vedenie sa často dajú poskladať z toho, čo už v programe je.

Ak k tomu pridáte správne zvolené moduly POHODA a vhodnú edíciu a verziu, mnohé požiadavky zaniknú ešte pred prvým riadkom kódu. Preto má zmysel investovať aj do školení: používateľ, ktorý pozná program, žiada menej vlastných úprav.

Extension a rozšírenia: najprv hľadajte hotové riešenie

Druhý krok je overiť, či problém už niekto nevyriešil. Pri POHODE sa najčastejšie ukazuje, že to, čo firma nazýva „vlastný modul“, je v skutočnosti bežné prepojenie: e-shop s účtovníctvom, váha so skladom, pokladnica s dokladmi. Podrobnosti o tejto téme nájdete v časti o integráciách POHODA.

Pred objednaním vývoja si položte tri otázky:

  1. Je požiadavka naozaj špecifická, alebo ju má rovnako aj väčšina firiem v odbore?
  2. Dá sa vyriešiť zmenou procesu, nie programu?
  3. Vyriešil by ju iný modul alebo iná edícia?

Ak na všetky odpoviete „nie“, vlastný vývoj je opodstatnený.

Ako vyzerá vývoj pre POHODU z technického pohľadu

Pri otázke, v akom jazyku sa pre POHODU programuje, treba hneď upresniť: do programu sa vlastný kód nevkladá. Vývoj prebieha vedľa neho a komunikuje s ním cez oficiálne rozhrania. To je dobrá správa, pretože hranica medzi štandardom a vašou úpravou je jasná.

XML rozhranie

Výrobca poskytuje XML rozhranie, ktoré umožňuje vymieňať takmer všetky údaje s externými systémami, napríklad so skladovým systémom, e-shopmi alebo pokladnicami. K nemu patrí dokumentácia so schémami XML a validátor schém. V praxi to znamená, že vývojár nehádá štruktúru dát: pripraví súbor, overí ho voči schéme a až potom ho odošle.

mServer

POHODA mServer je HTTP server zabudovaný v každej inštalácii. Prijíma a vydáva XML dáta cez požiadavky POST, podporuje HTTP aj HTTPS (odporúča sa HTTPS), kompresiu gzip alebo deflate a autentifikáciu Basic v hlavičke STW-Authorization. Dostupné sú koncové body:

  • /status na zistenie stavu,
  • /xml (POST) na import aj export,
  • /documents (GET) na získavanie dokumentov.

Dôležitý detail pre návrh riešenia: požiadavky sa spracúvajú synchrónne, jedna po druhej v poradí, v akom prišli. Ak vám e-shop posiela v špičke veľa objednávok, vývojár musí rozmýšľať o fronte, o opakovaní pri chybe a o tom, aby dlhá požiadavka neblokovala ostatné. Je to typická otázka, ktorou sa odlíši skúsený vývojár od začiatočníka.

Jazyk aplikácie, ktorá s mServerom hovorí, nie je obmedzený: stačí, aby vedela posielať HTTP požiadavky a pracovať s XML. Rozhodujúce preto nie je, v čom sa programuje, ale či sa tím vie o riešenie postarať aj o rok.

Ako vlastný vývoj ovplyvní aktualizácie POHODY

Najväčšia obava majiteľov firiem znie: „Keď si to upravíme, už nebudeme môcť aktualizovať.“ Pri správnom postupe to neplatí, a práve preto je dôležité, kde úprava žije.

Typ zásahu Riziko pri aktualizácii Čo urobiť
Nastavenie v programe Minimálne Overiť tlačové zostavy po novej verzii
Prepojenie cez XML alebo mServer Nízke až stredné Otestovať na kópii dát, skontrolovať schémy
Obchádzanie oficiálnych ciest Vysoké Neodporúča sa; prepracovať na podporované rozhranie

Osobitnú pozornosť si zaslúži legislatíva. Pri zmenách okolo e-kasy, kontrolného výkazu DPH alebo elektronickej fakturácie sa spoliehajte na aktualizácie od výrobcu. Vlastný kód, ktorý napodobňuje zákonnú funkciu, je presne ten, ktorý sa po zmene pravidiel stane nesprávnym a vy ho budete opravovať sami.

Pred každou novou verziou preto platí režim: kópia dát, test prepojení, až potom ostrá prevádzka. Ak ste zatiaľ nemali plánovanú podporu a údržbu, je vhodné ju dohodnúť spolu s vývojom, nie po ňom.

Bonnes pratiques: štandard, dokumentácia, testovanie

Dobrý vývoj sa pozná podľa disciplíny, nie podľa množstva kódu. Overené zásady:

Zostať pri štandarde

Každá úprava je dlh. Pýtajte sa pri každej požiadavke, či by nestačilo zmeniť postup. Účtovník alebo vedúci skladu často prijme malú zmenu procesu rád, ak ušetrí mesiace vývoja.

Dokumentovať

K vývoju patrí písomný popis: čo riešenie robí, aké údaje posiela, kde beží, kto má prístupové údaje a ako sa obnovuje po výpadku. Bez dokumentácie ste závislí na jednom človeku. Prístupové údaje sa v dokumentácii neuvádzajú, uloží sa len odkaz na ich správne miesto.

Testovať na kópii

Nový vývoj ani novú verziu programu nikdy neskúšajte prvýkrát na ostrých dátach. Kópia firmy, testovacie doklady a schválenie zo strany účtovníctva sú základ.

Zabezpečiť komunikáciu

Ak sa používa mServer, voľte HTTPS, ako výrobca odporúča, a prístupové údaje majte oddelené pre každé prepojenie. Súbor, ktorý sa pošle do POHODY, by mal prejsť validáciou voči schéme ešte pred odoslaním.

Ako posúdiť vývojára alebo intégratora POHODA

Vývoj sa rýchlo stane drahým, keď ho robí niekto, kto POHODU nepozná. Pri výbere si všímajte tieto veci:

  • Referencie z podobných projektov. Nie zoznam značiek, ale popis: čo prepájali, aký bol problém a ako ho vyriešili.
  • Znalosť rozhraní. Vie vysvetliť rozdiel medzi súborovou výmenou XML a komunikáciou cez mServer? Spomenie schémy a validátor?
  • Spôsob testovania. Má postup pre testovacie prostredie a pre návrat späť?
  • Odovzdanie. Dostanete dokumentáciu a prístupy, alebo len „funguje to“?
  • Podpora po spustení. Kto reaguje, keď po aktualizácii prepojenie prestane fungovať?

Ak neviete, kde začať, pozrite si stránku o výbere partnera pre POHODU a všeobecný návod na výber ERP intégratora. Naša služba je bezplatná: popíšete projekt a spojíme vás s intégratorom, ktorý sa zhoduje s vaším zadaním. Samotný projekt realizuje intégrator, nie my.

Kedy je rozsiahla úprava varovným signálom

Existuje hranica, za ktorou ďalšie zásahy už nedávajú zmysel. Typické príznaky:

  • Väčšina procesov firmy beží mimo programu a POHODA slúži len ako účtovná schránka.
  • Každá nová požiadavka vyžaduje samostatný vývoj.
  • Prepojení je toľko, že ich nikto nedokáže prehľadne opísať.
  • Aktualizácia sa odkladá, lebo sa nikto neodváži ju spustiť.

Vtedy je rozumné urobiť audit projektu a ak sa potvrdí, že program rastu firmy nestačí, porovnať možnosti pri migrácii. Nemusí ísť o zlyhanie: firma jednoducho prerástla pôvodný rámec.

Ako postupovať pri vlastnej požiadavke

Praktický postup, ktorý šetrí čas aj peniaze:

  1. Opíšte problém ako potrebu, nie ako riešenie („chceme vidieť stav objednávky v sklade“, nie „chceme modul“).
  2. Skontrolujte nastavenie a dostupné moduly.
  3. Overte, či ide o bežné prepojenie, a hľadajte hotové riešenie.
  4. Až potom nechajte intégratora navrhnúť vlastný vývoj s jasným rozsahom.
  5. Dohodnite dokumentáciu, testovanie a správu ešte pred začiatkom prác.

Tento postup funguje rovnako pre výrobnú firmu v Trnavskom kraji aj pre obchodnú spoločnosť v Košiciach: rozdiel je v procesoch, nie v metóde.

Zhrnutie

Vývoj POHODA je užitočný, keď sa drží štandardu a podporovaných rozhraní. XML rozhranie a mServer dávajú pevný základ pre prepojenia, no vyžadujú starostlivý návrh, testovanie a dokumentáciu. Najlepšia úprava je tá, ktorú sa podarí vyriešiť nastavením. Ak už vlastný vývoj potrebujete, hľadajte partnera, ktorý vie vysvetliť, ako bude riešenie vyzerať po najbližšej aktualizácii, nie len ako bude vyzerať dnes.

Často kladené otázky

Dá sa POHODA upraviť na mieru bez zásahu do programu?

Áno, a je to odporúčaný postup. Najprv sa využije nastavenie, potom hotové rozšírenia a nakoniec prepojenie cez XML rozhranie, ktoré umožňuje vymieňať takmer všetky údaje s externými systémami. Vlastný vývoj tak žije mimo programu a nemusí brzdiť jeho aktualizácie.

V čom sa programuje vývoj pre POHODU?

Samotný program sa nedopĺňa vlastným kódom vo vnútri. Vývojári pracujú s XML rozhraním, ku ktorému výrobca dodáva schémy a validátor schém, alebo s mServerom, teda HTTP serverom zabudovaným v každej inštalácii. Voľba jazyka aplikácie, ktorá s nimi komunikuje, je na vývojárovi a vašom prostredí.

Zničí vlastný vývoj aktualizáciu POHODY?

Nemal by, ak sa drží podporovaných rozhraní a nemení štandardné správanie programu. Riziko vzniká pri úpravách, ktoré obchádzajú oficiálne cesty. Pred každou aktualizáciou preto treba otestovať prepojenia na kópii dát a overiť, že schémy XML stále vyhovujú.

Ako overím, že vývojár POHODY vie, čo robí?

Požiadajte o ukážku podobného prepojenia, o popis spôsobu testovania a o dokumentáciu, ktorú odovzdá. Dobrý vývojár hovorí o XML schémach, o autentifikácii a o spracovaní chýb, nie len o termíne. Rovnako sa pýtajte, kto bude riešenie spravovať po odovzdaní.

Kedy je lepšie zvoliť iný ERP namiesto rozsiahleho vývoja pre POHODU?

Ak sa vaše procesy dajú pokryť len množstvom vlastných zásahov, je to signál, že program už nesedí na rozsah firmy. Vtedy má zmysel porovnať alternatívy a zvážiť migráciu. Pomôžeme vám nájsť intégratora, ktorý posúdi, či je lepšie rozšíriť POHODU, alebo prejsť na iné riešenie.

Zdroje

  1. STORMWARE – XML rozhranie POHODA
  2. STORMWARE – POHODA mServer pre vývojárov

Uvedené názvy softvéru sú ochranné známky ich príslušných výrobcov a uvádzajú sa len na informačné účely. Táto stránka je nezávislá a nie je prepojená so žiadnym výrobcom.