NHibernate supports fields that are generated by the database, but in a limited way. You can mark a field as generated on insert, on update, or both. In this case, NHibernate doesn’t write the field’s value to the database, but creates a select statement that retrieves its value after update or insert.

Ok, but what if you have a trigger that updates this field in some cases and sometimes doesn’t? For example, you may have a document number that is generated for some types of documents, and set by the user for other types. You cannot do this with NHibernate in a regular way – but there is a workaround…

It is possible to map multiple properties to the same database column. So, if you make a non-generated property that is writable, and a generated read-only property, this works. You have to be careful, though, because the non-generated property’s value won’t be refreshed after database writes.

A more secure solution would be to make one of the properties non-public and implement the other one to support both functionalities. Like this:

//
// This field is used only to send a value to the database trigger:
// the value set here will be written to the database table and can be consumed by
// the trigger. But it will not be refreshed if the value was changed by the trigger.
// 
private int? setDocumentNumber;	

private int? _documentnumber;

//
// The public property that works as expected, generated but not read-only
//
public int? DocumentNumber
{
	get { return _documentnumber; }
	set
	{
		// NHibernate is indifferent to this property's value (it will not
		// be written to the database), so we have to update the setDocumentNumber
		// field which is regularly mapped
		_documentnumber = value;
		setDocumentNumber = value;
	}
}

Here’s the NHibernate mapping for these two:

<property name="DocumentNumber" generated="always" insert="false" update="false"/>
<property name="setDocumentNumber" column="DocumentNumber" access="field"/>

Najveća vrednost firme je stručnost: poznavanje posla i tržišta, znanje i procesi koji su usavršavani godinama. Međutim, kada je potrebno da softver to podrži nastaje ogroman problem jer programi su u suštini najčešće nefleksibilni. Aplikacije se prave da rade na određeni način, onako kako stručnjaci softverske kuće misle da je najbolje raditi posao. Gotova rešenja - čak i njihovo ime govori o tome da je tu priča prilično završena - su ili jeftina "univerzalna" rešenja koja implementiraju nekakvu neutralnu sredinu funkcionalnosti, ili skupi sistemi koji  forsiraju "best practice", dakle nešto što većina smatra da je najbolji način. Firma koja želi da softverski podrži svoje poslovanje je često svedena na tri opcije: da kupi jeftino "standardno" rešenje (koje najčešće pokriva samo knjigovodstvo ili se najviše koncentriše na njega), da kupi veliki ERP (koji je vrlo skup) ili da pravi sebi rešenje "od nule".

Šta je EDI?

EDI (Electronic Data Interchange) je standard za komunikaciju između informacionih sistema. Kao što e-mail omogućava razmenu informacija među ljudima, tako EDI prenosi informacije koje razumeju informacioni sistemi. Njegovim uvođenjem se eliminiše potreba za slanjem dokumenata faksom ili poštom i njihovim prekucavanjem, čime nestaje jedna cela kategorija problema i nesporazuma i štedi se na troškovima. Suština je jednostavna: ako jedna firma u svom sistemu kreira, recimo, porudžbinu za drugu firmu, ta porudžbina će se pojaviti u sistemu druge firme. pročitaj više...

EDIFACT i konverzija

U EDI komunikaciji je kao i u e-mail razmeni potrebno ili da oba učesnika razumeju isti jezik ili da postoji prevodioc. Najrasprostaranjeniji "zajednički jezik" za EDI je standard EDIFACT koji je definisan da pokrije što širi spektar upotreba i samim tim je relativno komplikovan. Eight Bit i e-Integration kao EDI provajder  nude svojim korisnicima standardno i uslugu prevodioca: ako korisnik već ima mogućnost da prima ili šalje dokumente u određenom formatu, postoji opcija pravljenja konverzije iz tog formata u EDIFACT. Konvertor se ugrađuje u EDI kliring centar i u tom trenutku korisnik može da razmenjuje tu vrstu dokumenta sa bilo kojim drugim EDI korisnikom povezanim na bilo kog EDI provajdera.

Vrste dokumenata

EDIFACT standard podržava veliki broj različitih poslovnih dokumenata. U svetu se najviše razmenjuju porudžbine, otpremnice i fakture i to je za veliku većinu korisnika dovoljno. Od ostalih tipova dosta su zastupljeni cenovnici, izveštaji o prodaji kao i inventar liste, a postoje i poruke koje automatizaciju dovode do najvišeg nivoa, kao što su na primer poruke za potvrdu prijema robe, promenu porudžbine, najavu isporuke, plaćanja, itd. U razmeni se retko koriste sve mogućnosti koje određena poruka pruža već se prenose samo neophodne informacije, što dodatno olakšava povezivanje. (Na primer, u određene vrste poruka moguće je smestiti različite logističke podatke koji definišu način transporta a koji većini korisnika nisu neophodni). pročitaj više...

Koristi

Samim tim što sistemi komuniciraju bez intervencije ljudi postiže se veća udobnost i pouzdanost u radu. Krajnji korisnici sistema i dalje mogu da vide sadržaj dokumenata u samoj aplikaciji, ali više nije potrebno da ih oni unose u sistem ili šalju putem mail-a, faksa i tome slično. Ovim se ostvaruje ne samo ušteda na vremenu potrošenom na prekucavanje već i zbog eliminacije kako grešaka tako i nesporazuma: ono što jedan EDI korisnik pošalje, garantovano se pojavljuje kod primaoca. S obzirom da je prosečna pretplata za EDI konekciju reda veličine prosečne pretplate za internet konekciju, jasno je da je i novčana ušteda prilična. pročitaj više...

Kako se povezati?

Povezivanje na EDI je relativno jednostavno: najveći zahvat je modifikacija korisnikovog informacionog sistema da podrži prijem ili slanje određene vrste dokumenata - a i to je neophodno samo ako podrška već nije prisutna. Poruke se primaju i/ili šalju u vidu fajlova koji se razmenjuju sa e-Integration EDI kliring centrom. Naša preporuka je da klijent instalira našu AS2 klijentsku aplikaciju koja ovu razmenu potpuno automatizuje, a osim toga je i najsigurniji i najpouzdaniji način komunikacije. Fajlovi mogu sadržati podatke u proizvoljnom formatu, a najbrža i najjeftinija opcija je da se koristi neki od formata čiju konverziju e-Integration podržava: mi u te svrhe preporučujemo korišćenje eRDS formata koji je kranje jednostavan. Najčešće se za početak uvodi jedan tip dokumenta, i u velikoj većini slučajeva su to upravo porudžbine, koje su po strukturi i najjednostavnije. pročitaj više...

Pouzdanost

e-Integration EDI serveri nalaze se u prostorijama Level 3 provajdera u Dizeldorfu koji je jedan od većih internet provajdera u Evropi. Za svaku od celina sistema sistema postoje rezervni serveri spremni da preuzmu funkciju ako primarni zataji, a takođe postoji kopija kompletnog sistema na rezervnoj lokaciji u prostorijama e-Integration-a u Ratingenu. Sa ovako postavljenom infrastrukturom praktično je nemoguće da dođe do prekida u radu, i dostupnost servera je 99,99%. Ipak, i pored toga, firma poseduje i osiguranje protiv eventualne štete nastale na strani korisnika zbog gubitka podataka.

Dodatne usluge

EightBit i e-Integration nude klijentima vrlo širok spektar usluga. U oblasti EDI razmene podataka praktično sve vrste komunikacije su podržane, od konverzija u i iz različitih formata podaka kao što su Excel i PDF preko starijih digitalnih kanala komunikacije kao što je X.400 pa sve do faksa i pošte... Podvlačimo da je u slučaju Excel i PDF fajlova kao i faksa podržana dvosmerna komunikacija, dakle i slanje i prijem: ako vaš partner ima mogućnost da šalje samo faksove ili PDF-ove te informacije svejedno mogu da prođu kroz e-Integration clearing centar i da se pojave u vašem sistemu kao standardna EDI poruka. Kao proširenje usluge razmene podataka, e-Integration nudi i uslugu digitalnog potpisa i arhiviranja dokumenata, s obzirom da je takođe zvanični sertifikacioni autoritet.

Sa svoje strane, EightBit zaokružuje sliku time što se koncentriše na lokalni, "in house" aspekt poslovanja: s obzirom da je naša primarna orijentacija razvoj poslovnih informacionih sistema, u mogućnosti smo da upotpunimo EDI rešenja izradom funkcionalnosti koje su potrebne na samoj lokaciji klijenta. Bilo da je u pitanju podrška kompletnom poslovanju (u kom slučaju nudimo naše gotove ERP/CRM aplikacije) ili dopuniti funkcionalnost postojećeg sistema (npr. implementirati B2B ili B2C web portal za partnere koji nisu EDI povezani ili uraditi samo neki aspekt razmene podataka), EightBit poseduje iskustvo i tehničko znanje da na  visokokvalitetan način ispuni i najteže zahteve.

EDI Reference

Nemačka kompanija e-Integration je jedan od najvećih EDI provajdera u Evropskoj Uniji, firma koja je kao nekadašnji deo Dojče post bila pionir u razvoju EDI i čiji stručnjaci su učestvovali u definisanju samog standarda. Na teritoriji EU, SAD i Kanade e-Integration ima oko 6.500 povezanih firmi. Među za nas poznatijim klijentima nalaze se Metro Group, DM, British Petrol, Siemens, DHL, Lidl, Kuehne & Nagel, Karstadt, Vaillant, Unilever, Springer, itd...

Koji su preduslovi za uvodjenje EDI-ja?

Pored članstva u GS1 organizaciji (i uzimanja GLN i EAN kodova) i odabira vašeg EDI provajdera, potrebno je da obezbedite internet konekciju i to je sve ako ste mali dobavljač koji koristi webEDI usluge. U slučaju da želite potpuno automatizovan sistema potrebna je i mala dorada na vašem ERP rešenju koja bi omogućila import i eksport podataka u odredjenom formatu.

Koliko EDI košta?

Inicijalna cena uvodjenja EDI-ja uopšte nije velika ako se uzmu u obzir uštede koje se pritom postižu. Naša ponuda zavisi i od nivoa usluge koju ste izabrali. Na primer, ukoliko ste izbrali WebEDI opciju inicijalna cena iznosi 1 EUR, a ukoliko ste izabrali EDI Classic inicijalna cena iznosi 300 EUR. Pored ovoga, u oba slučaja postoji i varijabilni mesečni trošak koji direktno zavisi od količine isporučenih i iskonvertovanih dokumenata. Kompletan cenovnik možete skinuti ovde.

Za uvođenje EDI-ja potrebna je određena intervencija na mom informacionom sistemu. Moguće je da to neće proraditi "iz prve", da li ću zbog toga nepovratno izgubiti dokumente?

U generalnom slučaju ne: na primer, informacioni sistemi koje koriste trgovinski lanci često imaju mogućnost rada u testnom režimu. U tom periodu, tokom uspostavljanja i provere EDI komunikacije, poruke se šalju i dalje metodom kojim su se slale do tada (faks, e-mail...) paralelno sa slanjem putem EDI-ja. Na taj način korisnik ima mogućnost da proveri da li je sve korektno implementirao.

Da li uvođenje EDI-ja nameće krutu disciplinu po pitanju razmenjenih dokumenata? Na primer, šta se dešava ako ne mogu da isporučim porudžbinu koju sam primio preko EDI razmene?

EDI je samo jedan vid prenosa podataka. Korisnika ništa ne sprečava da na primer u dogovoru sa poručiocem otkaže primljenu porudžbinu, ili čak da mu poručioc izdiktira novu porudžbinu telefonom. Ali ako je potrebno da se zvanično evidentira promena dokumenta, postoje posebne EDI poruke za to. Na primer, postoje EDI poruke za promenu i potvrdu porudžbine, ali to je samo viši nivo automatizacije. EDI u suštini služi da na efikasan način prenese podatke iz jednog sistema u drugi, a šta će se dalje sa njima dešavati nije u njegovoj nadležnosti. Sa druge strane, EightBit u partnerstvu sa e-Integration-om nudi usluge digitalnog potpisivanja dokumenata, čime se garantuje da sadržaj dokumenta nije menjan: ali to je već druga tema.

Zašto EDIFACT a ne XML?

XML je samo standard za "pakovanje" podataka, on ne definiše značenje podataka koji se prenose. Postoji beskonačan broj načina na koji podaci o npr. fakturi mogu da se spakuju u XML, ali samo jedan način da se spakuju u EDIFACT.

Zašto EDIFACT a ne neki drugi standard (GS1 XML, CIMP, OAGI)?

Razlog je praktične prirode: EDIFACT je format koji je najrasprostranjeniji i maltene svi ga razumeju. Ovo pitanje bi donekle moglo da bude ekvivalentno pitanju "Zašto engleski a ne esperanto?". Esperanto jeste definisan kao univerzalni jezik, ali engleski je taj koji svi razumeju, prema tome on je standardan. Međutim, e-Integration kliring centar je tako napravljen da EDI korisnik uopšte ne mora da ima dodirnih tačaka sa EDIFACT-om: njemu je omogućeno da razmenjuje podatke u formatu koji njemu odgovara.

Zašto neko ne bi sam implementirao kod sebe konverziju iz EDIFACT-a ili u EDIFACT i primao poruke direktno umesto preko provajdera?

Ovo je potpuno legitimna opcija: postoje čak ERP aplikacije koje mogu same da primaju direktno EDIFACT poruke. Međutim, razlozi za i protiv su slični razlozima za, recimo, držanje svog web ili e-mail servera. Za tako nešto vam je potrebna kvalitetna infrastruktura, internet konekcija i serveri koji su dostupni preko 99% vremena, stručno i obučeno osoblje itd. a to je možda suviše skupo da bi se održavala jedna EDI veza: neuporedivo je jeftinije iznajmiti tu uslugu od provajdera koji svoje troškove deli na više hiljada korisnika i može da angažuje vrhunske administratore, servere i komunikacionu opremu i da ih stalno unapređuje.

Da li podržati "in house" format ili format vašeg EDI provajdera?

Svaki "in house" format bilo vaš ili vašeg EDI provajera je uproščeniji od samog standarda, što je svojevrsna prednost jer se ne gubi vreme na razvoj na podršku za funkcionalnosti koje se ne koriste. U slučaju korišćenja vašeg internog formata, problem može da nastane kada se ustanovi da je potrebno menjati strukturu formata jer nije dobro strukturiran ili ne sadrži sve potrebne informacije ili je ponovo u fazi da mora detaljno da se istestira. Generalno, EDI provajderi imaju više iskustva u razmeni EDI poruka i poznaju mnogo različitih standarda koji su višegodišnjim korišćenjem dovedeni do savršene upotrebiljivosti, istestirane kroz milione uspešnih transakcija. Stoga smatramo da je ipak bolja varijanta podržati predloženi "in house" format vašeg EDI provajdera, čime kompletna odgovornost pada na njihov teret.