Yleiskatsaus

Tämä merkintä esitetään kuvataan todellinen MRO (Huolto, Korjaus ja toiminta) hyväksynnän työnkulkuprosessia missä MOSS.

Tämä ei ole avoimesti tekninen keskustelu, mutta sen sijaan palvelee reaalimaailman esimerkki, joka osoittaa, miten MOSS platform tapasi reaalimaailman.

(Tämä merkintä on rajat lähetetty välillä http://paulgalvin.spaces.live.com ja http://blogs.conchango.com)

Tausta

Seuraavassa ominaista MRO asiakasprosessin

• Manuaalista hyväksyntäprosessi.
• Tukea käyttäen excel-laskentataulukot.
• Epäsäännöllinen hyväksyntäprosessi. Sama MRO hyväksynnän ostoprosessin vaihtelevat päivittäin, henkilö.
• Paljon paperia ja käsinkirjoitettu allekirjoitus — tarvitaan jopa ostoehdotukset 3 Kirjallinen allekirjoitukset ennen lopullista hyväksymistä.

Hankkeessa mukana tavoitteiden:

• Täysin automatisoida.
• Yrityksen käytäntöön hyväksyttäväksi.
• Antavat konsolidoidun kuvan MRO osto yhteistyöhankkeisiin.
• Yksityiskohtainen kirjausketju.

Haittavaikutuksena liuoksen, Kirjallinen allekirjoitusta ei enää tarvita.

Hyväksyntäprosessi

Hyväksyntäprosessi koostuu "uida nelikaistaiseksi": Aloittaja, Suora esimies, Esimies ja johtaja.

Aloittaja:

Näe tarvetta ostaa ja aloittaa prosessin. Huomaa, että maksumääräyksen voivat tai eivät voi todella tehdä ostoehdotus, mutta sen sijaan suoraan toisen toimihenkilön siihen. Joskus, aloittaja ei ole tekninen asiantuntemus täyttää PO ostoehdotuksen. Esimerkiksi, käyttäjä voi haluta hankintalistan uuden kannettavan tietokoneen, mutta ei tiedä paras myyjä, SEN mukaista, jne. Tässä tapauksessa, Aloittaja toimii ja se todella täyttää ehdotuksen.

Suora esimies:

Tämä on lähettäjän esimies (joka voi olla erilainen kuin henkilö, joka todella tuli PO ostoehdotuksen MOSS). Suora johtajien on hyväksyttävä PO ostoehdotuksen, ennen kuin järjestelmä hakee aluksi hyväksyntää edelleen ruodussa.

Esimies:

Toiminnallinen johtaja on henkilö, joka on vastuussa siitä, että ehdotetulla hankinnalla noudattaa yrityksen standardeja soveltamisalaan erityisesti yrityksen toiminta. Esimerkiksi, SE ostaa hyväksyy IT-esimies.

Toiminta-alueen johtaja:

Jako johtajat ostoehdotusprosessia tiukasti dollarin summa. Johtaja ostoehdotusprosessia konfiguroitavissa dollari määrältään.

Ratkaisu

Käytimme seuraavia työkaluja ja komponentteja toteuttaa ratkaisu:

MOSS: Toimii foorumi, jonka kaikki muu "roikkuu". MOSS tarjoaa kallioperän turvallisuussyistä, päätietoihin, kirjausketju ja muita ominaisuuksia.

InfoPath forms services-ohjelmassa: MOSS-komponentti, Näin käyttäjät voivat täyttää ostoehdotusten web-selaimella.

SharePoint Designer (SPD): Käytimme SPD toteuttaa automaattisen työnkulkuprosessin.

Verkkopalvelu: C#-verkkopalvelusta tehostaa käyttökokemusta mahdollistamalla CSS valinnat luettelot InfoPath-lomakkeen ja tarjoaa paremman suorituskyvyn osalta tietojen suodattamisesta. Ks. Täällä tekninen syvä sukellus tästä aiheesta ja siitä, miksi käyttää sitä.

Mukautettuja luetteloita: MOSS käyttäjäprofiileja tietyn käyttäjän suoraan Manager-ohjelman, mutta ei ole suurin osa tiedoista, joita hallita työnkulun päätöksiä (virrankatkaisu. Onko divisioonien manager vaaditaan hyväksymään PO ostoehdotuksen). Mukautettuja luetteloita käytetään "-Yritystiedot" sivusto säilyttää tietoja, kuten "Jaetun hallinnan hyväksyntää dollarin summa", "Toiminnallinen aluepäällikkö" ja niin edelleen. Luettelot hienosti integroitu InfoPath ja myös luoda, päivittää tai poistaa (LIKA) toimintoja valvonta- ja kättelyssä.

Käytä asia

Tämä Käyttötapaus osoittaa, miten ratkaisu sopii yhteen:

1. Paul haluaa uuden kannettavan. Hän kuvaa hänen tarpeisiinsa Vivek, IT henkilö tuntee yrityksen laptop standardit, Ensisijaiset toimittajat, jne.
2. Vivek kirjautuu MOSS, käyttää PO hankintalistan lomakkeen ja syöttää ostoehdotuksen puolesta Paul. Lomake kysyy Vivek osto-luokka, joka käyttää web-palveluja asuttamaan avattavasta luettelosta yrityksen hyväksymää myyjät. Vivek määrittää myös yritysten toiminta-alueiden osto (virrankatkaisu. "SE" tai "Rahoittaa").
3. SPD perustuu työnkulku alkaa, määrittää Paavalin esimies ja reitittää ehdotuksen esimiestään, Stacy.
4. Stacy hyväksyy ostoehdotuksen.
5. SPD työnkulun tarkastaa ehdotuksen ja määrittää, se on se hankinta. Se reitittää työnkulun toimiva tietohallintopäällikkö, Wonson.
6. Wonson hyväksyy ehdotuksen.
7. SPD työnkulku uudelleen tarkastaa ehdotuksen ja määrittää ostaa määrä ylittää maxium dollareina ja reitittää sen jako valvojalle hyväksyntää varten.
8. Alue-esimies hyväksyy ostoehdotuksen.

Muistiinpanot

• Käyttää tapauksessa osoittaa "puhdas" Suorita ilman hylkäämisestä tai hyppää.
• Jokainen hyväksyjä on mahdollisuus hyväksyä tai hylätä ehdotuksen sekä kommentteja. Nämä ovat kirjautuneena kirjausketju.
• Jos vastaava projektipäällikkö hylkää ostoehdotus missään vaiheessa, PO ostoehdotuksen on "kuollut" ja prosessi on aloitettava alusta.
• Työnkulku ilmoittaa asiasta alulle prosessin jokaisessa vaiheessa.
• Ei kirjoitettu allekirjoitus — määrittää asiakkaan (jälkeen joitakin voimakkaita suosituksia) että kirjausketju mukaisesti kautta Työnkulkuhistoria, tiedoksi niiden valvonnan tarpeisiin.
• Vaivaa — kesti noin kolmen miehen viikkoa toteuttaa tämän ratkaisun.

Johtopäätös

Tämä ratkaisu hyödyntää MOSS kehitys-ja runtime-ympäristö. Asiakas on voinut hyödyntää MOSS ydinominaisuudet automatisoi rutiini liiketoimintaprosesseja, joka vaikuttaa lähes jokainen yrityksen työntekijä. Lukuun ottamatta yksinkertainen web-palveluun (joka puolestaan hyödyntää MOSS), ei varsinainen "ohjelma" tarvittiin.

Ratkaisu toimii näyteikkunana"" asiakkaan, osoittaa kuinka erilaisia MOSS ominaisuuksia yhdistämällä luoda täysin varustellun business-sovelluksen ja tuottaa uusia konsultointi mahdollisuuksia tulevaisuudessa.

Sanasto

MRO: Huolto, korjaus- ja toiminta. Nämä ostot ovat yleensä esimerkiksi Lehtiöt, tuolit, henkilökohtaiset tietokoneet, tulostimet, matkapuhelimet ja vastaavat.

Tämä voi olla selvää monille, mutta kun opiskelu MOSS ohjelma tentti, Olen oppinut, että on melko helppo saada todellinen XML kyselyn kautta käyttäjä liitäntä.

Yksi nopea tapa on:

• Access Tarkennettu haku.
• Suorittaa haun, joka palauttaa tietoja.
• Muokkaa sivua (kautta sivuston asetukset).
• Muuttaa XSL seuraavasti:

<?XML versio="1.0" koodaus="UTF-8"?>
<XSL:Stylesheet versio="1.0" xmlns:XSL="http://www.w3.org/1999/XSL/Transform">
<XSL:lähtö menetelmä="XML" versio="1.0" koodaus="UTF-8" luetelmakohta="Kyllä"/>
<XSL:malli ottelu="/">
<Pre>
<XSL:Kopioi ja Valitse="*"/>
</Pre>
</XSL:malli>
</XSL:Stylesheet>

• Humauttaa anoa.
• Selaimen lähdekoodi.

Huomaa, että <Pre> Tag ei tee paljon kuin palvella kätevä merkki, kun tarkastelet tuloksia.

Tämä temppu voi olla erittäin hyödyllistä, kun hallittujen ominaisuuksien käsitteleminen ja mukauttaminen. Siinä luetellaan käytettävissä xslt, joka olisi ollut erittäin hyödyllistä XML viime 25 kertaa olen luonut mukautetun haun tuloksia.

Tämä pitäisi toimia dataviews sekä, Vaikka en ole testannut että ulos vielä.

Huomaan, että Eric Kraus kohtasi vaatimus tavallisesti täytetyiksi sisältökysely-web-osan. Ongelma? Hän oli puhdas WSS-ympäristössä CQWP vailla. Sen sijaan vuonna sikiön asemaa curling (halu on taisteltava joka päivä, näyttää siltä), Hän keksi ratkaisun, joka ainakin antaa WSS kauppoja mahdollisuus onnistua. Se on kuvattu Täällä.

Stefan Goßner on koonnut hirveä 4-osainen sarja SharePoint-sisällön ja käyttöönoton API Täällä. Tarjolla on hyvä katsaus ja erittäin hyviä esimerkkejä koodi (C#).

Ensimmäinen piristyi tämän linkin joris poelmans blogi http://jopx.blogspot.com/.

Jos olet kuten minä, siinä ei ole tarvinnut tehdä paljon käytännön työtä sisällön hallinta, Tämä on hyvin arvoinen 20 minuuttia ajastasi lukea.

Käyttäen API, voi:

• Viedä ja tuoda sisällön helposti.
• Uudelleen vanhemman sisältöä. Jos haluat viedä sisältöä sivustosta "A" ja lähettää sivustoon "B" mutta täysin uusi paikka hierarkiassa, Tämä on mahdollista.
• Vietävä sisältöä sivuston A ja tuoda valitut bittiä toimipiste A.
• Linkitä uudelleen sisältöä (tarkoitus käsitellä kaikki hyperlinkit).

Joku internets pyysi siitä, miten luoda lasketun sarakkeen luetteloon, joka näyttää muotoiltu arvo"[Käyttäjä] – [Tila] – [Sijainti]" kuten "Paul Galvin – Juominen [Ilmainen] Olut – Beach".

Paul mennä ja päivittää hänen kohta kotona haluttaa, ja lasketun sarakkeen päivittää asianmukaisesti. Sen [Käyttäjä] tulisi oletusarvoisesti käyttäjän luettelon kirjoittamalla ja päivittämisestä.

Laskettua saraketta ei voi käyttää "haihtuvien" toimintoja, kuten [Me] tai [Tänään]. Minä ratkaisin sen testiympäristön seuraavasti:

1. Luo teksti saraketta nimeltä â € œCurrent Käyttäjä".
2. Aseta oletusarvo [Me]
3. Luo lasketun sarakkeen nimi "Calc Test".
4. Asento sen arvo = [Nykyinen käyttäjä]

Menin, lisätty kohteen luetteloon, ja se toimi.

Olen vaivannut tämän 9 kuukautta ja nähdä, että ihmiset MSDN ja Usenet foorumeilla on too.l

Joskus, Kun word-asiakirja (tai muita doc) asiakirjasta Kirjasto saa Internet Explorerin kaatumaan ja mene pois (Kun kaikki välilehdet sen kanssa, jos jokin näistä Avaa).

Tämä MS korjaustiedosto saattaa ratkaista: http://support.microsoft.com/kb/938888

Myös, on joitakin kuvaus ongelmasta täällä:

http://jopx.blogspot.com/2007/07/solving-internet-explorer-crash-when.html

Yleiskatsaus:

Luonut mukautetun luettelon, jota hallinnoi sisältötyyppi, jolla joitakin kymmeniä sarakkeita.

Lisätty sivulle ja SPD, muunnetaan tiedot.

Ongelma:

Xpath-lauseke oli palaamassa tyhjää saraketta nimeltä "Tilanne". Olen viitataan sen thusly:

    <taulukon reunan = "1">
      <XSL:kullekin select = "/ dsQueryResponse/rivi/rivi," >
        <TR>
          <TD>
            Nykyinen tila:
            <XSL:arvo-ja select="@Current_x0020_Status"></XSL:arvo>
          </TD>
        </TR>
      </XSL>
    </taulukko>

CT-sarakkeessa on nimetty "Nykyinen tila". Se näkyy haun niin "Nykyinen tila". Kaikkialla näytät, näet "Nykyinen tila".

Kun selkäsauna mielettömästi noin, etsiskellä ajaksi liuos, Sen sijaan viitataan "@Recruiter" kummaa! — että todella palannut takaisin nykyinen tila. Odotin sitä palata takaisin rekrytoija, kun tein että.

Ratkaisu:

Olen pisti (SPD). Mene tälle sivulle (SPD) ja näyttää tietonäkymässä. Voit tarkastaa todellisten tietojen ja niihin liittyvien Xpath antaneet näkymään. Tässä huomasin, että todellakin, suunnattu "Recruiter" Xpath. Kumma, "todellinen" recruiter kenttä, johon osoitetaan "Recruiter1".

Noutoruoka:

SPD tarjoaa arvovaltainen Xpath-lausekkeita rivit & sarakkeet tietonäkymässä.

Toinen, se näyttää todelliset tiedot. Niinpä esimerkiksi, Tyyppi-sarakkeessa näkyy tämä:

<nobr><span><HREF="/sites/Corporate/HumanResources/TalentAcquisition/_layouts/userdisp.aspx?ID = 17 ">Galvin, Paul</A><IMG border ="0" korkeus = "1" leveys = "3" src="/_layouts/images/Blank.gif"/><href = "ohjelman:’ onclick = "IMNImageOnClick();palauttaa false;’ Class = "ms-imnlink"><IMG nimi = "imnmark’ otsikko =” Border =’0′ korkeus ='12’ leveys ='12’ src='/_layouts/images/Blank.gif’ ALT = "ei tavoitettavuustietoja’ SIP ='PGalvin@xxx.com’ ID = "imn_77, tyyppi = smtp" /></a></span></nobr>