Újabban egyre többen megteszik, hogy a számítógépen létrehozott számlát pdf formátumban lementik és azt tovább küldik partnerüknek. De ez ma, Magyarországon még nem megengedett. Ugyan kiállítási oldalon nem tud nagy problémát okozni, de a befogadó oldalán annál inkább, amikor az APEH nem fogadja el a számlát egy ellenőrzés során. Amennyiben elektronikus számlát szeretnénk kiállítani abban az esetben két megoldás áll rendelkezésünkre. Az EDI és a PKI. Ez utóbbi szolgáltatást nyújtja SAP Business One rendszerhez a BX eDOC+ AddOn.

Az EDI (Electronic Data Interface) nem más, mint két cég magállapodása, hogy a számlákat egy zárt rendszerben elektronikusan küldik át egymás között, azaz azokat nem nyomtatják, hanem például egy anyavállalati SAP rendszerből elektronikus zárt rendszeren keresztül átküldik egy leányvállalati SAP rendszerbe. Az elektronikus úton kiállított számla annak hitelessége ellenőrizhetősége érdekében eredeti formájában őrzendő meg. AZ EDI alapú elektronikus számla az azt kibocsátó rendszerben általános követelményeknek megfelelően kell megőrizni.

A PKI (Public Key Infrastructure) alapú elektronikus számla esetén a kibocsátó köteles az által kibocsátott PKI számlát legalább fokozott biztonságú elektronikus aláírással és időbélyeggel ellátni. A PKI számla kiállításához a szerződés létrejöhet ráutaló magatartás révén – így akár egyéb hitelesítés nélkül, webform kitöltésével, vagy ÁSZF-re hivatkozással – is lehetséges szerződést kötni ahhoz, hogy valamely vevő részére elektronikus számla kerüljön kibocsátásra.

A PKI alapú elektronikus számla megőrzésének az archiválási szabályokban meghatározott részletes követelményeknek megfelelően kell megtörténnie, amely szerint a megőrzési kötelezettséget a kötelezett (a számla kibocsátója, illetve adóalanyiságtól függően egyes számlabefogadók) akár saját maga, akár archiválási szolgáltató igénybevételével teljesítheti. Amennyiben a kötelezett maga végzi a megőrzést, úgy az archiválási szabályokban meghatározott követelményeknek megfelelő eljárási és/vagy informatikai feltételek biztosítása a kötelezett feladata.

A BX eDoc+, az SAP Business One rendszerhez teljes körűen illesztett BX bővítmény, amelyet a VariaTech Consulting Kft. és a NetLock Informatikai és Hálózatbiztonsági Szolgáltató Kft. közösen fejlesztett ki. Lehetőséget biztosít felhasználóinak, hogy mind nem minősített (fokozott biztonságú, joghatása: írásbeliség), mind minősített elektronikus aláírással (ami teljes bizonyítóerejű magánokirattal egyenértékű joghatással bír) és időbélyegzővel ellátott számlát bocsássanak ki és azokat hiteles elektronikus bizonylat formájában őrizzék meg.

És mi az ami mindig felmerül az emberben? Nézzük a leggyakoribb kérdéseket:

Mi van egy adóellenőrzéskor?

Adóhatósági ellenőrzési eljárásban a megőrzésre kötelezettől a rendszer dokumentációjának bemutatását, illetve az adóhatóság által közzétett formátumú másolat rendelkezésre bocsátását kérheti, illetve a számlázási folyamatot figyelemmel kísérheti számla kibocsátása közben.

A törvényi előírások szerint 5-10 évig kell megőrizni minden számviteli bizonylatot. Az elektronikusan előállított, majd időbélyeggel ellátott számla a joghatásnak megfelelő módon tárolódik az SBO rendszerben, amelyről automatikusan különböző szintű mentés készül. Szemben a papíralapú megőrzéssel a számla bizonylata nem tűnhet és nem amortizálódhat el.

A digitálisan aláírt PDF file és annak másolata hiteles példánynak számít?

Igen.

Kinyomtathatom az elektronikus számlát?

Igen, de az magában nem számít hiteles példánynak, annak elektronikus formátumát elkérhetik egy ellenőrzéskor.

Mi van ha nem áll rendelkezésemre az elektronikus példány?

Amennyiben én vagyok a kiállító ilyen nem történhet meg, hiszen a törvény előírja az adat tárolási kötelezettséget
Amennyiben én csak befogadtam egy elektronikus számlát nincsen semmi baj, ha nem áll rendelkezésemre elektronikus formában az, hiszen a kibocsátó köteles azt tárolni és azt számomra elérhetővé tenni kérésemre.

Nézzük először ki köteles jelentést leadni, azaz ki lesz adatszolgáltató és mit kell leadnia:

Az Intrastat adatszolgáltatói azok a magyarországi vállalatok/vállalkozások, amelyek EU-tagállam(ok)ból terméket hoznak be (beérkezések), vagy oda terméket visznek ki (kiszállítások).

A fentiek közül csak azoknak a gazdasági szervezeteknek kell adatot szolgáltatniuk, amelyek 12 havi EU beérkezése vagy EU kiszállítása meghaladja az adatszolgáltatási küszöbértéket, amelyet a KSH minden naptári évre előre kiszámít és közzétesz. A 2010-ben érvényes adatszolgáltatási küszöbérték a beérkezésekre és a kiszállításokra egyaránt 100 millió Ft volt.

A rendszer részére havonta, részletes adatokat kell szolgáltatni a tárgy hót követő 15. napig.

Az adatszolgáltatásnak az alábbi adatokat kell tartalmaznia:

• termék megnevezése,
• a termék 8 számjegyű kódja (CN8), VTSZ
• ügylet típusa,
• szállítási feltétel (fuvarparitás),
• fuvarozási mód (mi az a szállítóeszköz, amivel a termék elhagyja az országot),
• nettó tömeg (egész kilogrammra felkerekítve),
• mennyiség kiegészítő mértékegységben (azon termékek esetében, melyekre nem jellemző a kilogramm),
• partner ország,
• számlázott összeg (Ft)
  • ÁFA és adók nélkül,
  • fuvar és biztosítási díjjal együtt,
  • számla hiányában becsült összeg
• statisztikai érték (Ft)

Láthatjuk, hogy elég jelentős adatmennyiséget igényel tőlünk az EU. Ahhoz, hogy ezen adatok összegyűjtése ne egy pénzügyesünk, adminisztrátorunk dolga legyen minden hónapban sok-sok munkaóra alatt, ami alatt rengeteg egyéb hasznos dolgot tudna csinálni (pl.: pénzt termelni a cégnek), az SAP Business Onenal lehetőségünk nyílik ezt az információt gombnyomásra szolgáltatni.

De nem győzzük hangsúlyozni, hogy ahhoz, hogy ezt az adat halmazt szolgáltatni tudjuk, be kell kapcsolni egy ingyenes Add-ont a rendszerünkben és az alap adatokat ki kell tölteni a partnertörzsben és a cikktörzsben pontosan, mivel a Business Oneban az intrastat, ezeknek az adatoknak a meglétét figyelembe véve tudja csak kitölteni az alapbevallást, amelyet később csv illetve xls tipúsú fájlba átemelve készül el a küldhető formátum.

A cég elektronikus banki rendszeréből kinyerhető fájlok gyors és biztonságos beolvasását követően, precízen és pontosan kiegyenlíthetőek azok a tételek, amelyek a bankkivonaton, mint tranzakciók megjelennek. Az banki terminál kapcsolat (interface) használata költséghatékony módszer a cégek részére, ugyanis a kivonatok sorainak egyenkénti rögzítése sokkal több időt vesz igénybe mint amikor egy mozdulattal beemeljük az akár közel 100 tételsorból is álló kivonatot, amelyben aztán pillanatokon belül csak jelölni kell a beazonosított kiegyenlítéseket, melyeket az SAP Business One egy gombnyomásra lekönyvel.

Az banki terminál kapcsolat segítségével összeállítható utalandó csomagok használata, mint segítség már nem is kérdés, hogy nem az elektronikus bankba visszük be akár órák alatt adott esetben az utalandó tételeket, hanem az SAP Business One-ban kijelölés után, átemeljük a bankba és csak utalni kell. Munkaórákat tudunk megtakarítani, amelyet a könyvelők, pénzügyesek esetleg értékes kimutatásokra tudnak fordítani.

Új SAP Business One rendszer bevezetésekor nem érdemes spórolni azon, hogy az SAP Business One-t futtató szervernek más komolyabb feladatokat is kiadunk. Vegyünk egy szervert és azt csak erre használjuk! Ugyanis amennyiben cégünk méretéből és a tranzakciók számából adódóan óriásira hízik az adatbázisunk, akkor bizony a legcombosabb hardvernek is komoly erőfeszítésébe telik kiszolgálni a felhasználókat. Lássuk be, hogy nem tanácsos ilyen körülmények között még fájlszervert, levelezőszervert és webszervert telepíteni rá, mert nem fogja bírni. De ha bírja is, könnyen elfogyhat a tárhely. Akkor pedig egy idő után nem lesz hova lementeni a napi rendszerességgel készülő biztonsági mentéseinket. Azokra pedig szükség van, méghozzá nem is kicsit.

Nem mellékes tény az sem, hogy ha valamilyen a rendszert komolyabban érintő változtatást végeznek a tanácsadók, akkor kérni fognak előtte egy tejes tükrözést az SAP Business One-t tartalmazó merevlemezről. Ez a tükrözés elkészülhet pár óra alatt, de ha mindenki itt tárolja az internetről letöltött zenéit, filmjeit és mindenféle alkalmazástelepítőt, akkor sokkal több ideig fog malmozni a tükrözést végrehajtó rendszergazda, a tanácsadó és ebből kifolyólag a cég és annak informatikai rendszert használni kívánó összes alkalmazott.

A 8.8-as verzió szakít az eddigi hagyományokkal, immáron magában foglalja az összes lokalizációt, tehát nem lehet probléma az A és B jelű rendszerek közötti különbségekből. Mikor vehetjük ennek hasznát? Például olyan esetben, amikor egy kínai cég magyar leányvállalatánál dolgozó kínai vezetőnek Ázsiára szabott verzióra lenne szüksége, mindenki más pedig a magyart használná.

Talán kevésbé hasznos, de felhasználói szempontból mégis a legszembetűnőbb a grafikus felület átdolgozása, ami új ikonokat is magában foglal. Természetesen a felhasználónak megmarad a régi kezelőfelület is, amennyiben ragaszkodik a jól megszokott látványhoz. Nagyon sok mindenben javult a rendszer.

Tulajdonképpen a 8.8-as változatra tekinthetünk egy óriási hibajavító csomagként is, amiben új kényelmi funkciók jelentek meg. Azonban az igazi újdonság a Crystal Reports nyomtatási kép- és jelentésszerkesztő alkalmazás megjelenése. Aki próbált már az SAP Business One-ban lévő szerkesztővel nyomtatási képeket készíteni, az tisztában van vele milyen nehézségek árán lehet szép és ízléses végeredményhez jutni. A Crystal Reportsra tekinthetünk megváltóként is ilyen szempontból, ugyanis egy rendkívül jól felépített és könnyen kezelhető alkalmazásról van szó, amivel – kis túlzással persze – percek alatt összedobhatunk egy nyomtatási képet vagy átfogó pénzügyi jelentést a menedzserek számára.

Mindazonáltal a program előnye nem csak a könnyű kezelhetőségből származik, hanem abból is, hogy gyakorlatilag bármilyen adatbázisból be tudja szippantani az adatokat, legyen az Excel tábla, MS SQL szerver vagy éppen IBM DB2. Természetesen nem csak külön-külön képes kezelni ezeket az adatforrásokat, hanem egyszerre is. Amolyan “egyik tábla innen, másik tábla onnan” alapon. Mi ezeknek az adatoknak a segítségével hihetetlen mélységű jelentéseket készíthetünk, amihez olykor nem árt egy kis SQL ismeret sem, de egy átlagos felhasználó puszta kattintgatásokkal is meglepő eredményeket érhet el. Aki pedig napi szinten dolgozna a Crystal Reports-szal, azt egy pár napos oktatással már haladó szintre is fel lehet vinni.

Már az SAP Business One 2007A-hoz is létezett önálló Crystal Reports alkalmazás, azonban a 8.8 hozta el az integrációt. Különféle vezérlőelemek (tokenek) segítségével már az SAP Business One-on belül is megjeleníthetjük az eredményeket, az elkészített nyomtatási képek és riportok pedig pár gombnyomással Crystal Reportsból kényelmesen exportálhatók a cég vállalatirányítási rendszerébe.

Első vagy még inkább nulladik lépés: kellene egy rendszer. Eddig világos, de mi alapján válasszunk?

Mint cégvezetők nem ismerjük a rendszereket, nem tudjuk, hogy amikor veszünk valamit, mit is veszünk, ellenben örülünk, ha egy rendszert kifizetünk, nem szeretnénk még rendszer-kiválasztási tanácsadásra is költeni, pedig azzal általában többet lehet hosszútávon spórolni, mint, ami annak a költsége. Ma Magyarországon több mint negyven különböző vállalatirányítási (angol rövidítéssel: ERP) rendszert kínálnak az informatikai cégek.

1.    Tudjuk, hogy mit szeretnénk! – Rendszert nem azért veszünk, mert az milyen trendi. Rendszert azért veszünk, mert valamilyen problémára, feladatra megoldást keresünk. Egy jó rendszer olyan, mint egy jó gyártó sor. Akkor érte meg, ha felgyorsítja, hatékonyabbá teszi a termelést, kereskedelmet, növeli a folyamatok átláthatóságát.

2.    Gondoljuk végig a folyamatainkat! – És itt ne csak az általános dolgokra koncentráljunk. Lehet, hogy az eladásaink 80%-ában ajánlatot adunk, amit megrendel az ügyfél, majd szállítunk és számlázunk. Ezt is tudjuk, de sokkal lényegesebb, hogy az egyedi dolgokkal tisztában legyünk már a rendszerkiválasztás előtt, mert a későbbiekben fejfájást okozhat, ha a rendszer nem tudja.

3.    Specifikáljunk, azaz írjuk le a követelményeket! – Rajzoljunk, írjunk, jegyzeteljünk. Ezzel a rendszert kínáló cégekéletét könnyítjük meg, amivel a saját időnkön is spórolunk. Készítsünk egy táblázatot, az igényelt funkcióval és 4 oszloppal: tudja/nem tudja/fejlesztést igényel/megjegyzés. Pl.:

Rendszerkiválasztási követelmények meghatározása

Ahol szükséges fejtsük ki jobban az adott funkciót, hogy egyértelmű legyen! A táblázattal jobban össze fogjuk tudni hasonlítani a rendszereket!

4.    Készítsünk „Long list”-et - azaz vegyük számba azokat a rendszereket/beszállítókat, amik/akik szóba jöhetnek és küldjük el a specifikációt, kérjünk előzetes ajánlatokat. (Figyelem! Konkrét ajánlatot a cég mélyebb ismerete nélkül nem tud adni egy komoly beszállító sem, aki tényleg jó munkát akar végezni, tehát a beszállítók figyelmét is hívjuk fel, hogy nagyságrendbeli ajánlatot szeretnénk kérni!) Ne csak az egyszeri költségekre koncentráljunk! Tudjuk meg mennyi a követési díj és mennyibe kerül a későbbi tanácsadás is!

Érdemes esetleg egy nyílt napot tartani egyszerre az összes potenciális beszállítónak, amikor mindenki eljöhet kérdéseket feltenni, illetve a bejövő kérdéseket és válaszokat mindenki számára elérhetővé tenni a saját érdekünkben.

5.    És jöhet a „Sort list” – Válasszunk ki 2-3 rendszert/4-5 beszállítót, amik/akik számításba jöhetnek és üljünk le velük részletesen átbeszélni a követelményeket.
Amikre figyeljünk, mert költséget jelent:

• Licenc ár
• Bevezetési költség (Mit tartalmaz?)
  • Folyamatok felmérése
  • Paraméterezés
  • Egyedi lekérdezések készítése (Hány darab?)
  • Bizonylatok egyedi nyomtatási képe
• Rendszerkövetési díj
  • Mit tartalmaz?
• Support tevékenységek költsége
  • Mibe kerül?
  • Mennyi idő alatt reagálnak?

Célszerű összehasonlítási alap lehet a rendszer pl.: 5 éves TCO (Total Cost of Owner – a tulajdonlás teljes költsége) kiszámítása, azaz adjuk össze a következőket: licenc+bevezetés+rendszerkövetés*5+becsült support (évi 4-10nap)*5. Ha a kapott eredményt visszaosztjuk 62-vel és a felhasználók számával, akkor megkapjuk egy felhasználó 1 havi költségét, ami arra is iránymutató lehet, hogy egy későbbi bővítés mennyibe kerülhet.

Egy rendszerkiválasztás hosszú és fáradságos folyamat, de megéri az időráfordítást, mert a cég jövője múlik rajta.

A Crystal Reports tervező felülete (Designer) külső alkalmazásként települ a rendszerbe, de az SBO menüjéből is mint külső alkalmazás (Crystal Designer) futtatható. Az SBO-ból való megjelenítéshez szükséges (runtime) modulokat külön kell telepíteni. A Crystal Reports AddOn (bővítmény) pedig riport nyilvántartási és futtatási kezeléssel egészíti ki az SBO rendszert. A Designerrel megtervezett riport rpt-file referenciája az SBO-ban egy nyilvántartási’(Manage reports) táblázatba felvehető, itt a megfelelő modulra való hivatkozás is megadható, így az a modulonkénti ‘Crystal Reports’ menüpont kiválasztásával is  megjelenik. A nyilvántartási táblázatból kiválasztott riportot az SBO a Crystal Reports megjelenítő (runtime) modulja segítségével külön ablakban megjeleníti.

A riport megjelenítéséhez az SBO rendszer a file hivatkozáson kívül más paramétert nem ad át, így az esetleges további felhasználói paraméterek bekérdezéséhez a Crystal Reports a saját paraméterbekérdező felületét használja.

Az SBO 8.8 esetén:

A Crystal Reports tervező felülete szintén külső alkalmazásként települ a rendszerbe, de az SBO-ból való megjelenítéshez szükséges (runtime) modulok, valamint a riportok adminisztrációs felülete az SBO standard részeként automatikusan települnek.

A Designerrel megtervezett riport rpt-file tartalma az SBO adatbázisában tárolódik, tehát nem külső file-ként tárolja az SBO rendszer. A Designerrel való módosításhoz a rendszer előbb egy ideiglenes file-ba kiteszi, majd a megváltozott riportterv visszakerül az SBO adatbázisába.

A megtervezett riportok felhasználói szempontból ugyan úgy beépülnek az SBO rendszerbe, mint a hagyományos belső PLD (Nyomtatási elrendezés tervező )-vel készült riportok. Ez több lényeges dolgot is jelent:

• A riport megfelelő elnevezéssel az SBO menürendszerbe illeszthető ‘beszámolóként’ a kívánt megfelelő helyre, úgy ahogyan a hagyományos riportok is.
• A riport az SBO-ból való futtatáskor az SBO-ból paramétereket vehet át az úgynevezett ‘token’-ek (‘adatcsomagok’) segítségével. Ezek használatával a felhasználó a riportok megjelenítéséhez szükséges paraméter megadást az SBO-ban szokásos paraméter megadási módon teheti meg. Sőt: a méltán kedvelt ‘lefúrási nyil’-al való részletező adatmegjelenítés lehetősége is meg van a Crystal Reports-os lekérdezéseknél.
• Az említett paraméter átadási mód (‘token’) ad lehetőséget arra is, hogy a riport ‘elrendezésként’ is használható legyen, így akár alapértelmezett megjelenítési elrendezésként is megjelölhetjük a különböző üzleti bizonylatokhoz.

Mindezekből láthatjuk, hogy az SBO 8.8 esetében jóval teljesebb és alapvetőbb integrációról beszélhetünk, mint az SBO 2007A esetén, mivel itt a felhasználói kezelés szempontjából teljesen el van fedve az, hogy az adott riporttervet milyen módon hozták létre, mégis élvezheti a felhasználó a Crystal Reports nyújtotta előnyöket.

A tanácsadó számára az esetek nagy részében ez az egyetlen kapcsolat biztosítja az elérést az ügyfél rendszere felé. Belépünk, látjuk az ottani gép képernyőjét és kezeljük a billentyűzetét. Mindezt bárhonnan, ahol van internet. Persze ha ilyen egyszerű lenne minden, akkor nem írnám ezeket a sorokat. Azonban az ilyenkor fennálló kapcsolat minősége és sebessége egyáltalán nem mindegy.

Tegyük fel, hogy az ügyfél 300 kilométerre van a tanácsadótól és olyan hibát tapasztal, ami miatt képtelen aznap termékeit gyártani, tehát dolgozni. Ilyenkor a tanácsadó fellép a rendszerre távoli asztal kapcsolattal, gyorsan kikeresi a hiba forrását, jó esetben saját maga meg is tudja szüntetni és a cégnek egy munkást sem kellett hazaküldeni, egy megrendelőtől sem kellett elnézést kérni. Ha azonban a tanácsadót percenként ledobja a távoli asztal elérés, vagy esetleg reménytelenül lassú, akkor nem tud mit tenni, le kell autóznia 300 kilométerre. Ez az ügyfél számára költség, mert a munkanap fele biztosan elúszott és a kiszállási díjat is meg kell fizetni. Mindezt azért, mert a szerver üzemeltetéséért felelős személy nem fordított kellő figyelmet egy megbízhatóan és problémamentesen működő távoli elérés létrehozására.

Egyébként, ha már a történetnél vagyunk érdemes tudni, hogy a legelső változat, pontosabban a Crystal Reports elődje 1984-ben íródott, akkor még Quick Reports néven, egy Kanadai hajózási társaság részére.

Később már Crystal Reports néven jelent meg, majd a (mai szemmel nézve) szerény DOS-os kereteket kinőve egyre jelentősebb szoftver rendszerré fejlődött, végül többszörös tulajdonos váltás után a Business Objects részeként 2007 vége felé az SAP tulajdonába került.

Ezáltal a Crystal Reports kétségtelenül még szorosabb és meghatározó kapcsolatba került az Üzleti Intelligencia (Business Intelligence) eszközökkel. Ezzel továbbra is megőrzi világpiaci vezető, sőt ma már standardnak számító szerepét az üzleti-vállalati riportkészítés területén, minthogy többszáz szoftvert Crystal Reports-al együtt szállítanak, többek között a Visual Studio .NET fejlesztő környezetbe is illeszkedik.

A különböző nyelvi változatok után nemsokára a magyar nyelvű változatot is használhatjuk, előbb a felület (ezt már bizonyos kiegészítő csomagok tartalmazzák), később a teljes súgó ill. dokumentációs rendszer lefordításával.

Ügyfeleinknél rendszeresen tapasztaljuk, hogy nincsen saját rendszergazdájuk, hanem külsős cégek segítségét veszik igénybe egy-egy probléma esetén. Pedig érdemes megfizetni egy IT-val foglalkozó főállású alkalmazottat, mert sok rejtett  költségtől kímélheti meg a céget.

Egy rendszergazda tökéletes SAP Business One kulcsfelhasználóként funkcionálhat a szervezeten belül. Egyrészt megvan a kellő tudása arra vonatkozóan, hogy miként kell telepíteni a frissítéseket és a klienseket. Másrészt gond nélkül megtanítható neki, hogy miként lehet teszt adatbázist létrehozni és egyéb alapvető műveleteket elvégezni a rendszerben.  A rendszergazda számos olyan hétköznapi feladatot el tud látni, amit az SAP Business One üzemeltetése megkövetel, de egy informatikai tudással alig rendelkező alkalmazott nem tud elvégezni. Fel tud szabadítani helyet, ha már betelt a szerver a sok biztonsági mentés miatt. Nem utolsó sorban pedig remek bejelentő lehet az SAP partnercég helpdesk rendszerében, azaz probléma esetén ellátná az összekötő szerepét a cég munkatársai és a tanácsadók között.