Programozó csapat kerestetik
2014-02-25T17:13:26+01:00
2014-02-26T13:16:37+01:00
2022-07-22T23:27:32+02:00
  • ebben igazad van, hiszen a kk-nak a szoftver csak egy munkaeszköz,
    Mutasd a teljes hozzászólást!
  • Ez egy speciális szakma. emberekkel kell tudni bánni, akik ráadásul még egymással szemben is ellenérdekeltek. Ennek semmi köze nincsen a szoftverhez.
    Mutasd a teljes hozzászólást!
  • nézd, lehet, hogy félreérthető voltam, 

    nyilván nem azt állítottam, hogy pld. az említett esetet integrálni kell a szoftverbe, mert nyilván nem szabad az ilyen egyedi esetekkel elbonyolítani,
    vélhetőleg azt papíron még a kk sem fogja az életben  megoldani, mert nem képes a matematikai modellt felállítani, nem is tud nekiállni, és nem a programozókat akarom lebecsülni, de szerintem az átlag programozó sem boldogulna vele, viszont, ha te vagy a fejlesztő, akkor meg valamilyen szinten elvárják tőled, hogy mégis megold (rendben, nem volt szó róla a specifikációban, meg "nem fér bele" a támogatásba, azaz simán "lerázhatod"),

    egyébként meg lehet, hogy én látom rosszul, de pont amiatt, mert hiába vannak szigorú szabályok a hivatal oldaláról a kezelővel, kk-val szemben, a lakókat nyilván általában ez nem érdekli, és nyilván elvárt valamilyen rugalmasság a kk-től, egyébként meg simán megfúrják, mint pld. nálunk is tette a többség,

    egy bér-munkaügy-tb rendszerre az "alkalmazott" szerencsére semmilyen befolyással nem lehet (normális esetben), az egyedüli "nyűg" a hivatalnak való megfelelés, akkor az ezek szerint egyszerűbb, nem? hiszen a hivatalos szabályok ismertek, meg persze átláthatók(?), nem?

    abban persze igazat adok neked, hogy ha tetszik, ha nem egy bér-munkaügy-tb rendszernél van egy szigorú "megfelelési kötelezettség", itt meg igazából azt implementálsz, amit akarsz, legfeljebb maradnak a papírmunkánál (legalábbis tudtommal az előbbi esetben jobban ki vagy szolgáltatva az elektronikus adatszolgáltatásnak, mint az utóbbinál),

    egyébként is miért lenne bonyolultabb egyik a másiknál? input-szabályrendszer-output, kell ezen gondolkodni?


    szerkesztve: ha sarkítani akarnám a dolgot, akkor azt is mondhatnám, hogy egy társasház kezelő programnak alapban része egy bér-munkaügyi-tb rendszer, mert a legtöbb nagyobb  társasháznak van egy sor alkalmazottja, nem?
    Mutasd a teljes hozzászólást!
  • Jelezném én is, hogy szerintem is nagyon el vagy tévedve. Én anno fejlesztettem társasház rendszert még clipperes időkben (win98/winnt kezdet környéke). Már akkor is akkora volt a falat, hogy évekig volt munka vele, és még mindig fele sem volt készen a cuccnak, amikor végül is feladtam, mert az ügyfelek már akkor is többet követeltek, mint amennyit fizettek (volt egy gazdasági visszaesés féle időszak akkoriban is). A bérszámfejtés és a társasház közül ha bármelyik is nagyságrenddel egyszerűbb a másiknál, az biztos, hogy csak a bérszámfejtés lehet.
    Mutasd a teljes hozzászólást!
  • Nézd . Mindegy, hogy az előző időkben mi történt. Ennek a rendszernek úgy kell működnie, hogy napi szinten rögzítik a forgalmat, mindenféle információt megkaphat a kuncsaft, meg a kezelő is a pillanatnyi állapotról. Itt listákat lekérdezéseket stb értek.
    Van egy havi zárás. Annak megvannak az eredményei, /pl.felszólítások., egyenlegek stb... listák, kimutatások. vagy pl. felszereltek két új vízórát leszereltek hármat ezt nyomon kell követni. Jön a következő hónap, és észreveszik, hogy öt évig valaholvalamit rosszul csináltak. Kiszámolják kézzel, és az eredményt egy /egyetlenegy/ bizonylaton felviszik a rendszerbe megfelelően kommentelve a megfelelő tipusú bizonylaton. Az előző hónaphoz TILOS nyúlni. Az már le van zárva. Számviteli törvény tiltja. Nevezzük ezt a bizonylatot pl. valamiféle helyesbítő bizonylatnak. Kész is vagy. Nem kell ehhez matematikai modell. Magának a szoftvernek egy már felépített, tiszta és világos szabályrendszernek kell megfelelnie. Pl: Ha a szabály az, hogy szemétdíjat négyzetméter alapján osztják el akkor azt annak megfelelően kell számolni, ha egységár van lakásonként, akkor úgy stb...
    Az, hogy öt évvel ezelőtt milyen hibákat követtek el a nyilvántartásban, könyvelésben annak semmi köze a program működéséhez. Csupán csak annyi, hogy a programnak azt le kell tudnia kezelni. 
    Pl. a folyamat : jegyzőkönyv lekönyvelés bizonylat. A rendszer naprakész.
    Nem ragozom tovább, de nem egy észveszejtően bonyolult rendszer.
    Mutasd a teljes hozzászólást!
  • nem akarok veled vitatkozni, de szerintem nem látod azt az alapvető problémát, ami miatt egy ilyen társasházi rendszer is rendkívül el tud bonyolódni,

    ilyen pld. az, amire p l_ is utalt, hogy esetleg időben visszafele kell kezelned bizonyos dolgokat,
    pld. láttam már olyat, hogy egyszer csak a kk rendet akart vágni az almérők ügyében, vagy valamelyik lakó akart a végére járni, azaz x lakásban a legkülönfélébb időpontokban beszerelt fogyasztásmérők, és természetesen az adott szolgáltató által az átvétel után később kiállított számlák alapján tisztázni akarták, hogy akkor ki hogyan áll a közöst tekintve, és mindezt mondjuk n évre visszamenőleg, miközben a szolgáltatási díjak is k-szor változtak, stb., nyilván fel lehet állítani erre egy matematikai modellt, és meg lehet oldani, ki lehet számolni, de szerintem a legtöbb programozónak ez meghaladná a képességét, és "többe kerülne", mintha azt mondanák, hogy holnaptól indítsunk tiszta lappal, és felejtsük el, hogy akkor ki mennyivel tartozik, vagy fizetett többet, stb. (azaz anyagilag senki nem járna vele jól, legfeljebb csak erkölcsileg), megéri?

    én nem akarom a két feladatot egymáshoz képest súlyozni, de míg szerintem egy bér-munkaügyi-tb rendszerben a törvényi változások folyamatos követése a "kihívás", addig egy társasház kezelő szoftverben az előre nem feltétlenül látható igényekhez az utólagos alkalmazkodás az, persze specifikálni kell a feladatot, oszt jó napot, de pont ez tipikusan egy olyan feladat, ahol még utólag jön a java, szerintem,
    Mutasd a teljes hozzászólást!
  • Pedig maga a megrendelő specifikálta a 2-5 ember / 3-6 hónapot. Ez alaphangon 6-30 emberhónap. 6-ba normális körülmények között nem tud beleférni, 1 hónap (2 emberrel 2 emberhónap) simán elmegy az információk begyűjtésével, egyeztetésével. Aztán lehet fejleszteni. 1 hónap alatt kész minden, 1 hónap tesztelés, javítás, utólagos módosítások? Lehetetlen. Ezért legyen 15-20 emberhónap. Ez már bőven a 10 millió körüli összeg, ha rendesen adózott tevékenységet feltételezünk. Márpedig tételezzünk fel.  Egy teljesen átlagos 420E bruttó bejelentett bér 15 hónapra 8 milliós bérköltséget jelent egy cégnek.  Szóval akkor miért is sok a 10 millió, ha netalán még nyereséget is szeretne termelni, és akár még rezsije is van? Vállalkozóként meg 40E Ft-os napidíj / havi 21 nap megint nagyon alacsony összeg.
    Mellékesen a program hibás működéséből - összecsapott, kevés tesztelés, stb. - eredő esetleges költségeket ki viselné?

    Mellékesen a számviteli  és egyéb vonatkozó törvények milyen sűrűn változnak? Van az a modell, ami ezt képes lekövetni 5 évig módosítás nélkül??? Nincs.
    Mutasd a teljes hozzászólást!
  • Nem vitatkozni akarok, de egy bér-munkaügy-tb rendszer már modell szinten is egy nagyságrenddel bonyolultabb feladat, mint egy ilyen társasházi rendszer. Az 5 évig való bizonylatmegörzés a bérre nem igaz mi /Ott még sok minden egyebet is meg kell örizni öt évig? Legyen kettős könyvelés. Ugyanmindegy. Egyébként tényleg úgy kell megcsinálni, hogy tudja azt, amit egy főkönyvi rendszernek tudnia kell. 
    A modellt kell jól kialakítani, és öt év mulva is le tudsz utólag könyvelni egy tételt. Csak ne sértsd meg a számviteli törvényt.
    Egyébként az egészet arra fel írtam, hogy 3-6 ember fél évi munkája, meg 10-15 millió
    Ft. Túlzásnak tartom.
    Mutasd a teljes hozzászólást!
  • Bér-munkaügy, könyvelő rendszer mellé főállású tanácsadó kell, a törvényi változásokat folyamatosan követni - agyhalál. Nem vállalnám be, sőt, nem is vállaltuk még be a jelen programunkban.
    Mutasd a teljes hozzászólást!
  • Igen, a bér-munkaügy évekkel ezelőtt egy "rémálom" volt, napjainkra azért nagyságrenddel egyszerűsödött...
    "Ez egy naplófőkönyv megspékelve egy-két mozgással." Hahahaha!
    Valóban sokan képzelik a társasházas ügyvitelt egy sima naplófőkönyvi-pénzügyi rendszernek.  Mindaddig, amíg például rá nem ébrednek, hogy az elévülési időn belül (5 év) minden lekönyvelt szám "mozoghat" benne (hónapokkal, évekkel később bejelentett adásvételek, utólag bejelentett létszám változások stb).
    Aztán le kell kódolni a lehetetlennél lehetetlenebb közös költség megosztási döntéseket, a saját - nem hiteles - almérők szerinti elszámolást egy-két-tíz almérőre.
    Mindezt cizellálja az egyszer albetét szintű, máskor tulajdonosi szemléletű egyenleg kimutatás. És ne is említsük az önkormányzatok több társasházon átívelő elszámolás igényét, vagy egy beruházó cég elvárásait az általa folyamatosan értékesített/bérbeadott lakásokkal, üzletekkel kapcsolatban.
    Mi a helyzet az osztatlan tulajdonban lévő gépkocsi beállókkal, teremgarázsokkal? Az ott helyet használók is fizetnek valamilyen mértékű közös költség hozzájárulást vagy bérleti díjat (máris kell egy számlázó modul is).

    Nem piskóta az egyidejűleg, ugyanazon albetéten nyilvántartandó több tulajdonos adminisztrációja, főleg ha köztük megoszlik az egyes költségnemek terhe (például bírósági határozat miatt). Vagy ha ugyanazon helyrajzi számon - például egy recepciós helyiségen - több tucat tulajdonosnak van bejegyzett tulajdon joga.



    A sima pénzforgalmi társasház könyvelés könnyen átmehet kettős könyvviteli kötelezettségbe, ami magával von egy szigorúbb számviteli szemléletet. De már pénzforgalmi könyvelésnél is elvárás a szállító nyilvántartás, szállítói karton, számlák rögzítése, függő számlák kimutatása.



    Finomságként jelenik meg a tulajdonostársak részéről - a fogyasztás elszámolás mellett - az egyidejűleg több, akár 5-6 egyenleg kimutatása (külön a közművekre, egyedi előírásra, felujítási alapra...). Mindezt úgy kell tudni könyvelni, egy konkrét befizetett összeget szétkontírozni több albetétre és több költségnemre, hogy a könyvelő ne kapjon tőle idegbajt.



    Ja! És napjaink slágere: a társasházas rezsi!



    Végül a lakók és számvizsgálók jogos elvárásai egy társasházi ügyviteli rendszerrel kapcsolatban:

    - idegen nyelvű outputok (angol, spanyol, német),

    - e-mail küldési lehetőség,

    - késedelmi kamat számítás (természetesen egyáltalán nem a megszokott szempontok szerint),

    - internetes ügyfélkapu biztosítása.



    Tovább is van! Mondjam még???


    :):):):)



    (10M alatt nem lehet piacképes TH alkalmazást szülni! És nagyon jóindulatú voltam...)
    Mutasd a teljes hozzászólást!
  • Akkor mennyiért vállalnál be mondjuk egy bér-munkaügyes rendszert ? Ami funkcionalitásában egy nagyságrenddel több. Ami ott az alanti rendszernél le van írva az csak egy egy oldalas papír. Pl. Jelenlét ív. stb... Nem kell ezt ennyire túlbonyolítani. Ez egy naplófőkönyv megspékelve egy-két mozgással. Meg banki tranzakciók kezelésével. Jól kell összerakni a modellt.
    Mutasd a teljes hozzászólást!
  • 2-3 ember társaságában sem vállalnám be 3 hónapra, 6-ra is neccesen, hogy az tesztelve, hibajavítva legyen, ha ezt az alapoktól kell megírni. Költségszinten is valahol 10-15 milliót mondanék rá, nettó, számlára. Megér ez ennyit?
    Mutasd a teljes hozzászólást!
  • Nem ilyen egyszerű minden illyes fajta program más logikával készül speciális.Kb 3 -6 hónapos a fejlesztés.
    Mutasd a teljes hozzászólást!
  • Nem azért kell csapat, hogy haladjon a projekt. A Program már a piacon van csak és jó százalékot foglal le a piacból de elavult és ezért kell a frissítés.
    Mutasd a teljes hozzászólást!
  • Ha van egy kész dobozos termék a piacon, akkor miért gondolná valaki is, hogy újra lefejleszteni olcsóbb, mint venni egy licenszet. Ha csak azért akar a megrendelő custom fejlesztést, hogy olcsóbban megússza, akkor már rég bukta az egész projekt, kivéve, ha hobbiból valkik megcsinálják neki, de elnézve a funkcionalitást az nem egy két hetes fejlesztés lenne.
    Mutasd a teljes hozzászólást!
  • Ezt_kell_tudnia. Gondolom azért kell a csapat, hogy olcsóbb legyen mint egy ilyen.
    Mutasd a teljes hozzászólást!
  • Nagyjából specializált könyvelőprogi. Legalábbis, amit èn láttam. De szerintem vannak kész progik a témában.
    Mutasd a teljes hozzászólást!
  • Üdv,

    konkrétan mit kell tudnia egy társasház kezelő programnak?
    Mutasd a teljes hozzászólást!
  • Programozó csoportot keresek 2-5 fő.

    Társasház kezelő program megírására. Régi program forráskóddal megvan az újra azért van szükség mert haladni kell a korral.

    Multi platform de inkább win és linux  mysql szerverrel (web is lehet de csak ha a kritériumoknak meg tud felelni itt értem a gyors gombok pl tab) skinezhető felület.

    Nyelv nem eldöntött nyitottak vagyunk mindenre.

    Projekt időtartalma 3-6 hónap körül számolunk.
    Fő állás mellett is vállalható aki tud rá szánni időt, de el kell készülnie a programnak.

    Jelentkezni privátban nálam. És egyéb kérdéseket is ott feltenni.

    Köszönöm
    Mutasd a teljes hozzászólást!
abcd