Asiakirjalle ei löytynyt muunnoskaaviota. Kuinka löytää virhe tietojen siirtämisessä

Oppikirja 1C Data Conversion (painos 2) Säännöt objektien muuntamiseen

Kuten jo tiedämme, objektien muunnossääntöjä käytetään kohteiden vastaamiseen lähde- ja kohdekokoonpanoissa. Luonnollisesti sääntö määrittelee tietolähdeobjektin (eli mistä tiedot saa) ja tiedon vastaanottajaobjektin (eli mihin data siirretään tai kirjoitetaan).

Niiden lisäksi on joukko ominaisuuksia, joiden merkityksen yritämme paljastaa.

Etsi kohdeobjektia lähdeobjektin sisäisen tunnisteen perusteella- lippu, joka määrittää objektien haun V8-alustan versiossa vastaanottimesta. Jos tämä lippu on valittuna, muokattavan kohteen haku vastaanotintietokannasta suoritetaan käyttämällä objektin sisäistä (ainutlaatuista) tunnistetta. Tämä tunniste ei näy käyttäjälle, ja ohjelma säilyttää tietokannan tunnisteiden yksilöllisyyden, joten kahdella tietokantaobjektilla ei ole samaa tunnistetta.

Jatka etsimistä hakukenttien läpi, jos vastaanotinobjektia ei löydy tunnisteen perusteella- lippu päättää jatkaa kohteen etsimistä vastaanottimen tietokannasta, jos haku yksilöllisen tunnisteen perusteella ei johda positiiviseen tulokseen.

Älä vaihda olemassa olevia objekteja vastaanottimessa latauksen aikana, vaan luo vain uusia ja täytä ne *- lippu määrittää, onko kohteen tietoja tarpeen muuttaa vastaanottimen tietokannassa, jos kohde löydettiin onnistuneesti yksilöllisen tunnisteen tai hakukenttien perusteella.

Älä luo uutta objektia vastaanottimeen, jos sitä EI löydy *- lippu määrittää, pitääkö vastaanottajan tietokantaan luoda uusi kohde, jos sitä ei löydy yksilöivän tunnisteen tai hakukenttien perusteella.

Kun siirrät objektia viittauksella, ÄLÄ luo uutta objektia, vaan siirrä vain viittaus- lippu määrittää, pitääkö vastaanottajan tietokantaan luoda uusi kohde, jos sitä ei löydy yksilöivällä tunnisteella tai hakukentillä, jos kohde siirretään viittauksella. Jos kohdetta ei löydy ja sitä etsitään yksilöllisen tunnisteen perusteella, vain linkki objektiin siirretään (ilman hakukenttiä - yksi linkki). Jos objekti puretaan suoraan (eli ei vain linkki objektiin, vaan myös kaikki sen tiedot), lippu ei vaikuta mihinkään.

Älä pura lähdeomaisuusobjekteja linkkien kautta- lippu määrittää, onko tarpeen purkaa kaikki kohteet, joihin lähdeobjektilla on linkkejä, vai riittääkö vain tiedot linkeistä näihin objekteihin. Oletetaan, että olet lataamassa tuotteen viitekirjaa. Jos vastaavassa PKO:ssa ei ole tätä valintaruutua valittuna, niin kohteen lisäksi kaikki objektit, joihin se viittaa, puretaan. Jos lippu on viritetty, kohteita, joihin nimikkeistö viittaa, ei pureta. Kokeile valita tämä ruutu ja tarkastella tuloksena olevaa tiedonsiirtotiedostoa, poistaa se ja vertailla tuloksia. Ymmärrät nopeasti sen merkityksen.

Älä muista kuormaamattomia esineitä- lippu määrittää, tarvitseeko järjestelmän CACHE viimeksi puretut kohteet purkamisen yhteydessä. Välimuistin avulla voit nopeuttaa tietojen lataamista ja lataamista.

Käytä nopeaa objektihakua lähetettäessä ja ladattaessa- lippu määrittää, käytetäänkö lähetettävien kohteiden pikahakua. On järkevää käyttää sitä pienelle määrälle hakemistomerkintöjä (merkintöjen määrä on enintään 1000 elementtiä). Vaikutus saavutetaan, jos monille objekteille on asetettu lippu Älä pura ominaisuusobjekteja viittauksella. Tällä tietojen lataamis- ja latausjärjestelmällä nopeus kasvaa useita kertoja.

Luo automaattisesti numero tai koodi, jos sitä ei ole määritetty- lippu määrittää, tarvitseeko järjestelmän automaattisesti luoda uusi koodi tai objektinumero, jos sitä ei täytetty ennen tallennusta.

Online-vaihto

Pura objekti (kokonaan) vain, jos siihen on linkki- asetus määrittää, missä olosuhteissa esine on purettava. Jos valintaruutu on valittuna, objekti puretaan seuraavien sääntöjen mukaisesti:

  1. Purkamissääntöjen mukaan, jos esine on jo purettu, pura se sellaisenaan
  2. Purkamissääntöjen mukaan, jos esinettä ei purettu, emme pura
  3. Kun lataamme linkin avulla kohteeseen, lataamme koko jutun

Esimerkiksi, jos sinun ei tarvitse siirtää koko tuotetta IS:stä toiseen, vaan vain sitä, johon on linkkejä, valintaruutu tekee sen.

Älä vaihda vastaanottimen tietokannassa luotua objektia latauksen aikana- asetus määrittää, onko tarpeen siirtää (takaisin) objekti, joka on luotu tietokannassa, jonka kanssa vaihto järjestetään. Eli jos dokumentti on luotu tietokannassa 1 ja tietokanta 2 syötetty vaihdon kautta, niin pitäisikö se siirtää tietokantaan 1, kun sitä muutetaan tietokannassa 2. Asetuksen avulla voit määrittää objektin prioriteetin vaihdon yhteydessä? sen luominen. Eli muutokset tietokannassa, jossa objekti luotiin, jaetaan kaikkialle, eivätkä muutokset muissa tietokannoissa vaikuta tähän tietokannan 1 objektiin.

Lataa objektin prioriteetti- asetus määrittää objektin prioriteetin latauksen aikana muutosten törmäyksen sattuessa. Oletusarvo ja tyhjän arvon tapauksessa on Above. Jos törmäys tapahtuu, ohjelma analysoi latausobjektin prioriteetin. Vain jos latausobjektin prioriteetti on yhtä suuri kuin Above, se tallennetaan vastaanottajan tietokantaan. Jos prioriteetti on Sama tai Below, ohjelma tallentaa vastaavat tiedot törmäyksestä tietokantaan, mutta ei muuta objektia.

Hakukentän asetusvaihtoehdot- taulukko mahdollisista vaihtoehdoista hakukenttien asettamiseen käyttäjälle. Sääntösuunnittelija määrittelee mahdolliset hakukenttien yhdistelmät, jotka käyttäjä voi valita vaihtoa perustaessaan. Kaikki säännön kehittäjän määrittämät asetukset on käsiteltävä "Hakukentät" -käsittelijäkoodissa. Käsittelijän SearchSettings-muuttuja määrittää käyttäjän valitseman hakuvaihtoehdon (SettingNameForAlgorithm vastaavalta taulukon riviltä). Jos käyttäjä ei valinnut mitään vastaavaa vaihtoehtoa tai hänelle ei tarjottu mitään vaihtoehtoa, hakuasetukset on tyhjä merkkijono.

"Lisäasetukset"-välilehdellä voit muokata säännön nimeä, sen sisällyttämistä tiettyyn ryhmään sekä säännön kuvausta.

Hyvää päivää rakkaat blogin lukijat. Tällä sivustolla on aiemmin julkaistu artikkeli muuntamisesta
, tämä artikkeli osoitti
kuinka voit perustaa vaihdon käyttämällä konstruktoreita, jotka luovat vaihtosääntöjä.
Tätä menetelmää voidaan käyttää muunnettaessa tietokantoja 1C-versiosta 7.7 versioon 8.2.
Nyt puhumme siitä, kuinka siirtää tietoja 1C 8.2 -kokoonpanojen välillä, jotka eroavat hieman toisistaan.

Tämän artikkelin pääpaino on asiakirjan taulukkoosan muuntamisessa, mikä tarkoittaa sitä
työskentelemme kanssa omaisuusryhmän muunnossäännöt - PKGS.

Valmistellaan PKGS:n määrittämistä – säännöt kiinteistöryhmän muuntamiseen

Siirrämme "Tavaroiden ja palvelujen vastaanotto" -asiakirjan, jossa on eroja "Tavarat"-taulukkoosion ALV-määrityksessä.
lähde- ja vastaanotintietokannassa. Lähdetietokannassa tämän attribuutin tyyppi on "DirectoryLink.VAT Rates",
ja vastaanottajatietokannassa - tyyppi "TransferLink.VAT Rates".

Muuten, mukavuuden vuoksi voit määrittää

Lisäksi vastaanotintietokannassa meidän on täytettävä "Account BU" -tieto, joka myös sijaitsee
asiakirjan "Tavaroiden ja palveluiden vastaanotto" taulukkoosiossa "Tavarat". Otamme täytettävät tiedot "Tilikirjanpito" -tiedoista.
hakuteos vastaanottimen kannan nimikkeistö.

Tilannetta mutkistaa se, että työskentelemme taulukkoosan kanssa, joten meidän on määritettävä
omaisuusryhmän muunnossäännöt - PKGS. Meidän on käytettävä taulukkoosion nykyistä riviä.

Luodaan muunnossääntöjä 1C-ominaisuuksien ryhmälle

Olemme jo kehittäneet muunnossäännöt "Tavaroiden ja palveluiden vastaanotto" -asiakirjalle.

Mutta "Tuotteet" -taulukkoosassa ei ole omaisuuden muuntamista koskevat säännöt"alv-kannat".
Sinun on lisättävä uusi omaisuuden muunnossääntö napsauttamalla "Synkronoi ominaisuudet..." -painiketta.

Näyttöön tulee valintaikkuna "Määritä omaisuuden muunnossäännöt (tavaroiden ja palveluiden vastaanotto)".

Sinun on toistettava mitä kuvassa tehtiin ja napsauta "OK" -painiketta.

Vaikka olemme luoneet kiinteistöryhmän muunnossääntö, mutta se ei ole vielä valmis.
Muista, että taulukkoosion "ALV-kannat" tiedot vaihtelevat arvotyypeittäin.
Lähdetietokannassa tämän attribuutin tyyppi on "DirectoryLink.VAT Rates",
ja vastaanottajatietokannassa - tyyppi "TransferLink.VAT Rates". Meiltä puuttuu sääntö
Muuntaminen hakemistosta luetteloon.

Tapahtumakäsittelijät omaisuusryhmän muunnossäännöille

Jotta voit määrittää ominaisuuden muuntamisen oikein, sinun on luotava uusi objektin muunnossääntö.

Näkyviin tulevassa valintaikkunassa ilmoitamme, että ALV-hinnat -hakemisto on muutettu samannimiseksi siirroksi.

Tälle säännölle ei ole omaisuuden muuntamissääntöjä.
Siksi, kun tallennat tämän säännön, valitse "Ei" näkyviin tulevasta valintaikkunasta.

Dialogissa, jossa on kysymys "Luo tietojen lataussäännöt?" Valitaan myös "Ei".

Kaksoisnapsauttamalla avaamme valintaikkunan, jossa määritetään objektimuunnossääntö (PKO) "alv-kannat".
Valitse tässä "Tapahtumankäsittelijät"-välilehdestä "Purjattaessa" -tapahtuma ja määritä "Lähde" ​​ja
"Linkkisolmu", eli mitä siirretään.

Jos Lähde. Arvo = 0 Sitten
LinkNode = "Bid0" ;
ElseIf lähde. Panos = 12 Sitten
NodeLinks = "Bet12" ;
ElseIf lähde. Nimi = "ilman arvonlisäveroa" Sitten
NodeLinks = "Ilman ALV" ;
Loppu Jos ;

Kun olet kirjoittanut käsittelijän, napsauta "OK"-painiketta.

Käsittelijöiden tiedoissa:

Lähde - Mukautettu - ladattu lähdeobjekti (linkki tai mukautetut tiedot).
Linkkisolmu - alustettu xml-linkkisolmu. Voidaan käyttää
esimerkiksi alustaaksesi muiden objektien ominaisuuksia.

Osoitamme nyt nimenomaisesti tämän objektin muunnossäännön käytön, kun poistamme "ALV-kanta"-attribuutin.
Siirry "Tavaroiden ja palveluiden vastaanotto" -asiakirjan "Ominaisuuksien muuntaminen (*)" -välilehteen ja avaa muunnos
ominaisuusryhmä "Tuotteet", kaksoisnapsauta "ALV-hinnat" -ominaisuutta ja avautuvassa valintaikkunassa "Sääntö"-kentässä
valitse muunnossääntö ALV-kanta-objektille.

Napsauta "OK"-painiketta.

Nyt meidän on vain asetettava kirjanpitotilit nimikkeelle määritettyjen arvojen mukaisesti.
Siirrytään "Objektin muunnossäännöt" -välilehteen, etsitään "Tavaroiden ja palveluiden vastaanotto" -objekti ja
Kaksoisnapsauttamalla sitä avautuu objektin muunnossäännöt (OCR) -valintaikkuna.
Siirrytään "Latauksen jälkeen" -tapahtuman "Tapahtumakäsittelijät" -välilehdelle ja kirjoitetaan seuraava:

Jokaiselle LineTCH From Object. Tuotteiden kierto
LineTC. AccountAccountBU = LineTC. Nimikkeistö. TiliTiliBU;
EndCycle ;

Ladataan nyt nämä säännöt lähteeseen käyttämällä ulkoista käsittelyä "Universal Data Interchange in XML Format" - "V8Exchan82.epf".
Ladataan tiedot xml-tiedostoon. Avaa sitten sama käsittely vastaanotintietokannassa ja valitse ladattava xml-tiedosto ja lataa tiedot.

Muuten, "Universal Data Interchange in XML Format" -käsittely voidaan avata valikkokohdan kautta
"Palvelu" | "Muu tiedonvaihto" | "Yleinen tiedonvaihto XML-muodossa". Tästä kirjoitettiin vähän muistiinpanossa.

Tiedetään, että 1C-ohjelmat ovat kätevä ja monikäyttöinen työkalu kirjanpidon automaatioon, joka sopii yrityksille monilla eri toimialoilla ja toiminta-alueilla. Tämä työkalu on kuitenkin monimutkainen, ja valitettavasti sen kanssa työskenneltäessä ilmenee usein erilaisia ​​​​virheitä. Tässä artikkelissa näytämme, kuinka voit löytää ja ratkaista virheen, joka tapahtui siirrettäessä tietoja käyttämällä luomia sääntöjä Tiedonmuunnostekniikat 2.0. Mitä minun tulee tehdä, jos lataus epäonnistuu tai tietojen lataaminen vastaanottavaan tietokantaan on mahdotonta? Artikkelimme pyrkii vastaamaan näihin kysymyksiin.

Joten jos olet ostanut tietojen muunnossäännöt, avannut käsittelyn siirtoa varten, asettanut kaikki asetukset, mutta lataus keskeytyy ja palveluviesteihin tulee virheilmoitus, tässä on muutamia tekniikoita, joiden avulla voit löytää ja poistaa virheen.

Tarkista ensin ohjelman julkaisuversiot säännöissä määritetyillä versioilla. Pienellä versioiden välisellä erolla lähde ongelmia ei ilmene, mutta jos julkaisusi on huomattavasti viimeisimpiä versioita jäljessä, säännöt eivät toimi. Asetusversio vastaanotin on oltava identtinen säännöissä määritellyn kanssa.

Mistä voin nähdä, mitä julkaisuja säännöt koskevat? Avaa vain sääntötiedosto millä tahansa editorilla (oletusarvoisesti se voi olla Internet Explorer tai Notepad) ja katso ensimmäiset rivit - ne sisältävät lähteen ja kohteen versiot.

Kuva 1. Katso säännöt

Mitä tehdä? Jos sinulla on tällainen mahdollisuus, päivitä lähdeohjelma muunnossäännöissä määritettyyn julkaisuun. Jos et voi päivittää ohjelmaa, et voi työskennellä näiden sääntöjen kanssa.

Mutta ehkä olet jo tehnyt kaiken tämän, ja lataus tapahtuu edelleen virheineen? Yritä sitten löytää ongelmallinen elementti, joka estää ohjelmaa latautumasta oikein.

Esittelemme toiminta-algoritmia virheiden etsimisessä esimerkkinä tietojen siirtämisestä KA 1.1:stä BP 3.0:aan.

Toimi seuraavasti: poista kaikki siirtosäännöt käytöstä ja pura yksittäiset sääntöryhmät yksitellen. Nuo. yritä ensin vain purkaa Kirjanpitopolitiikka, sitten vain Saapuvat saldot, vain Hakemistot jne. (Kuva 2). Useimmiten ongelmia syntyy asiakirjoja purettaessa, kun taas muun tyyppiset kohteet puretaan normaalisti, joten harkitaan niiden esimerkkiä jatkotoimenpiteitä varten. Nyt sinun on toistettava prosessi vaihtoehtoisella latauksella kunkin asiakirjan muunnossäännön kanssa. Nuo. puolestaan ​​lataa vain ennakkoraportit, vain siirretty remburssi jne. luettelon mukaan, kuten kuvassa 3 näkyy.

Kuva 2. Esineryhmien peräkkäinen purkaminen

Kuva 3. Objektityyppien purkaminen yksitellen

Oletetaan siis, että lataus keskeytyy, kun kaikki lataussäännöt on valittu Dokumentointi. Latasit kaiken tyyppisiä dokumentteja yksitellen, kävit kaikki paikat yksitellen läpi ja laskit, että virhe tapahtuu vain esimerkiksi dokumentteja ladattaessa Toiminta (kirjanpito ja verokirjanpito). Seuraavaksi sinun tulee vähitellen kaventaa latausaikaa ongelmallisen asiakirjan löytämiseksi. Lataa ensin vuosineljänneksen, kuukauden tai viikon mukaan, kunnes löydät päivän, jolloin lataus epäonnistuu.

Mitä tehdä? Jos onnistut löytämään virheen aiheuttaneen asiakirjan ja näet, mikä ongelma todennäköisimmin on, hienoa. Korjaa asiakirja, jos mahdollista, tai älä yksinkertaisesti siirrä sitä - on paljon helpompi korjata yksi asiakirja kuin tehdä koko siirto manuaalisesti. Jos haluat suorittaa siirron ilman vain yhtä asiakirjaa, käytä valintaa viereisessä ikkunassa. Aseta "Vertailutyyppi" -sarakkeeseen "Ei yhtä suuri", valitse "Arvo"-kohdassa ongelmallinen asiakirja ja jatka lataamista tavalliseen tapaan.

Kuva 4. Asiakirjan valitseminen latauksen aikana

Okei, mutta entä jos lataus on suoritettu oikein, mutta tietoja ei voi ladata toiseen tietokantaan? Ota ensin aikaa ja tarkista uudelleen, oletko tehnyt kaiken oikein ja vastaavatko ohjelmaversiot. Toisin kuin lähde, vastaanottimen julkaisuversion on vastattava tiukasti säännöissä määritettyä, muuten saat aina virheilmoituksen.

Mitä tehdä? Latausvaiheen virheet voidaan useimmiten korjata vain purkuvaiheessa, joten ongelman etsimismenettely on sama kuin yllä kuvattu, vain yhtä poikkeusta lukuun ottamatta - jokaisen purkamisen jälkeen on tarpeen toistaa lastaus, jotta löytää vastaanottavassa tietokannassa olevaa elementtiä, jota ei ladata. Noudata samaa järjestystä - siirrä ensin joukko objektinäkymiä, sitten tietyt näkymät tiettyjen päivämäärien mukaan ja poista lopuksi ongelmallinen kohde, joka estää onnistuneen lataamisen.

Kun vakiokäsittely ei pysty suorittamaan latausta oikein ja prosessi pysähtyy, palvelusanomissa näkyy aina virheilmoitus. Joissakin tapauksissa on todella mahdollista löytää tämän virheen sijainti ja syy vain purkamalla erityyppisiä esineitä yksitellen. Tämä ei kuitenkaan ole ainoa tapa. Usein virheen syy paljastetaan jo palveluviestissä, sinun tarvitsee vain lukea se oikein.

Katsotaanpa esimerkkiä purkamisesta KA 1.1. Käyttäjä purkaa lähdetietokannasta Saapuvat saldot vuoden 2018 alussa. Purkuprosessi keskeytyy ja ohjelma näyttää useita palveluviestejä, mukaan lukien seuraavat:

Virhe tapahtumakäsittelijässä BeforeProcessingUploadRules
PVD = Jäljellä olevat_materiaalit
Käsittelijä = BeforeProcessingDataUpload
DescriptionErrors = Virhe haettaessa kohteen ominaisuuden arvoa (lähdeomaisuuden nimen mukaan)
PKO = Nimikkeistö (Hakemisto: Nimikkeistö)
PKS = 15 (artikkeli --> artikkeli)
Objekti = hitsauskoneen invertteri VDI 160R (kiinteä omaisuus)
Vastaanottajan ominaisuus = artikkeli (merkkijono)
DescriptionErrors = Objektikenttää ei löydy (artikkeli)
ModulePosition = Processing.UniversalXMLDataExchange.ObjectModule(8283)
Viestikoodi = 13
ModulePosition = Processing.UniversalXMLDataExchange.ObjectModule(1694)
Viestikoodi = 31

Voisi mennä vaikeimman tien ja purkaa erityyppisiä saldoja yksitellen (käyttöomaisuuden jäännökset, aineettomien hyödykkeiden saldot jne.) ja todeta, että virhe tapahtuu purettaessa säännön mukaan Jäljellä olevat_materiaalit. Tai näet välittömästi säännön nimen virheilmoituksessa. Katso, viestin virhetranskription ensimmäinen rivi sanoo juuri tämän. DVP - tietojen lataussääntö. Tietojen lataussääntö on yhtä suuri kuin Remaining_Materials. Meidän ei tarvitse etsiä mitään, ohjelma itse kertoo, missä virhe tapahtui.

Riisi. 5.1. Palvelun virheilmoitus

Yhtä helposti voimme löytää syyn. Linjassa DescriptionErrors kirjoitettu Ei kovin selkeä viesti käyttäjälle. Ymmärrämme kuitenkin, että virhe piilee jossain kohteen ominaisuudessa. Mikä esine? Rivillä ilmoitettu Esine tässä viestissä. Tässä tapauksessa tämä kohde on Hitsauskoneen invertteri VDI 160R (Kiinteä omaisuus). Jo tällä hetkellä voit huomata ristiriidan. Tietojen lataussääntö nimeltään Jäljelle jääneet materiaalit, linjassa Objektin muunnossääntö (OCR) kirjoitettu Nimikkeistö, miksi objektityyppi kirjoitetaan muodossa Kiinteä omaisuus? Tutkitaan lähdetietokantaa ja tarkistetaan, löysimmekö todella oikean objektin.

Tilin 10.09 “Varasto ja taloustavarat” saldoista löydämme ongelmallisen kohteen - subconto Hitsauskoneen invertteri VDI 160R(katso kuva 5.2)

Riisi. 5.2. Tilin tase 10.09 vuodelta 2018

Jos avaat tämän alikonton, näet sen heti Hitsauskoneen invertteri VDI 160R on todellakin perustyökalu, ei nimikkeistö (katso kuva 5.3). Mitä jää jäljelle Hitsauskoneen invertteri VDI 160R osoittautui tilille 10.09 täysin ilmeiseksi virheeksi, joka pitää korjata.

Riisi. 5.3. Käyttöomaisuuskortti Hitsauskoneinvertteri VDI 160R

Purkuvirhe johtuu tässä tapauksessa väärästä objektityypistä. Ylijääneiden materiaalien purkamista koskevan säännön mukaan ne tulee purkaa Nimikkeistö- materiaalit, polttoaine, varasto jne. Tällaisilla kohteilla on tietty joukko ominaisuuksia, jotka siirretään toiseen tietokantaan muunnossäännön mukaisesti. Objekteille, joilla on tyyppi Pääasia ominaisuusjoukko on täysin erilainen. Tällaista esinettä ei voi purkaa materiaalien purkamissäännön mukaan. Ohjelma tunnistaa kohteen nimellä Nimikkeistö mutta ei löydä siitä tarvittavia ominaisuuksia eikä näin ollen voi muuntaa sitä tiedostoksi kirjoittamista varten. Näin sanottiin viestissä Virhe haettaessa kohteen ominaisuuden arvoa (lähdeomaisuuden nimen mukaan).

Tässä esimerkissä ongelma voidaan ratkaista melko helposti - säännöissämme on parametri Älä pura saldoa, jos määrä on nolla. Kun se on asennettu, vaakoja, joiden määrä on nolla, ei yksinkertaisesti pureta. Kuten kuvassa 5.2 esitetystä taseesta näkyy, tämän osakonton saldoilla ei ole määrää, ts. tämä ongelmallinen jäännös voidaan helposti poistaa käyttämällä määritettyä parametria.

Muissa tapauksissa, kun objektia ei voida sulkea pois suodattimen tai parametrin avulla, käyttäjän on korjattava lähdetietokannan virhe ennen tietojen siirtämistä.

Esimerkki virheestä.

Katsotaanpa esimerkkiä toisesta tiedonsiirron aikana havaitusta virheestä.

Yritessään ensimmäisen kerran ladata asiakirjoja käyttäjä näki seuraavan tekstin järjestelmäviesteissä. Virheilmoituksen avulla voimme ohittaa virheen havaitsemismekanismin ja jatkaa sen korjaamista. Tällaisia ​​viestejä ei aina näy, ja joskus joudut silti etsimään virhettä yksitellen purkumenetelmällä. Olemme jo keskustelleet edellä siitä, kuinka tällainen viesti luetaan.

Kuva 6.1. Virheviesti

Joten ohjelma itse kertoo meille ongelmallisen asiakirjan - tämä on Lasku ostajalle IPBP-000008, mikä tarkoittaa, että menemme heti asiakirjaan ja yritämme selvittää, mikä virhe on.

Kuten kuvasta 6.2 näkyy, tässä dokumentissa taulukko-osion ”Tavarat ja palvelut” jollekin riville asetetaan nimikeryhmä, ei itse nimike, mikä itsessään on virhe. Tämän asiakirjan muunnossäännöt eivät tietenkään määrittele, kuinka objekti muunnetaan tästä taulukkoosasta nimikkeistön ryhmä, tämä on täysin erityyppinen elementti kuin itse nimikkeistö, ja ohjelmalla ei ole tietoa elementin siirtämisestä muuta kuin säännöissä määritettyä tietoa. Siksi muunnosprosessi ei tunnista sitä, ei voi muuntaa sitä ja antaa virheen.

Kuva 6.2. Asiakirja, jossa on virhe

Se, miten ja miksi tämä perustettiin, ei kiinnosta meitä tällä hetkellä. Päätämme olla siirtämättä asiakirjaa, mikä tarkoittaa, että jätämme sen pois siirrettyjen objektien luettelosta. Asiakirjan lataussäännön löytäminen Lasku ostajalle maksamisesta, valitse se, siirry valintaan, aseta kenttä - linkki, vertailutyyppi - ei yhtä suuri, arvo - ongelmadokumenttimme. Näin ollen poistamme tämän asiakirjan siirrettyjen kohteiden luettelosta ja latauksen pitäisi tapahtua normaalisti.

Kuva 6.3. Asiakirjojen poissulkemisen asetusten määrittäminen

Tämän jälkeen voit jatkaa lataamista sinulle sopivalla tavalla - siirtää kaikki asiakirjat kerralla tai siirtää vain Laskut maksua varten, paitsi löydetty tosite, ja sitten siirtää loput - tiedonsiirtojärjestys voi olla mikä tahansa.

Tässä on huomattava, että käsittelyssä on mahdollisuus valita kohteita GenericXML Data Exchange ei kaikissa tyypillisissä kokoonpanoissa. Tarkemmin sanottuna tällainen toiminnallisuus puuttuu hallitun sovelluksen tilassa. Erityisesti vakiokokoonpanossa Integroitu automaatio versio 1.1 Voit työskennellä sekä tavallisessa sovellustilassa että hallitussa sovellustilassa tai, kuten he myös sanovat, hallinnoitujen lomakkeiden tilassa. Ensimmäisessä tapauksessa valinnat standardikäsittelyssä ovat mahdollisia (katso kuva 4), toisessa - ei. Sitten sinun on käytettävä käsittelyn modifioituja versioita (katso kuva 6.3). Jos kokoonpanoa käytetään alustan yhteensopivuustilassa 8.2 (tämä on erityisesti KA 1.1 Ja UPP 1.3), käsittely on tarpeen GenericXML Data Exchange versiot 2.1.7 . Jos yhteensopivuustilaa ei käytetä, kuten kokoonpanossa Enterprise Accounting -versio 3.0, sinun on työskenneltävä versionkäsittelyn kanssa 2.1.8 . Näissä hoidoissa on myös lisäominaisuuksia lokikirjan valintojen täyttämiseen (lisätietoja), joten ne eivät sisälly kaikkiin toimitusvaihtoehtoihin, vaan ne ovat aina ostettavissa joko osana paketteja, joissa on merkintä elämänhistorian mukaisella valinnalla, tai erikseen.

Tältä näyttää yleisesti ottaen prosessi 1C-tietojen siirron aikana tapahtuneen virheen löytämiseksi ja poistamiseksi.

Löydät muita hyödyllisiä materiaaleja Artikkelit-osiosta tai pääsivustoltamme.

© Anna Balyasnikova, viimeisimmät muutokset huhtikuussa 2018

Tämän vaihtosäännön tarkoituksena on siirtää keskinäisten selvitysten saldot BP 2:sta UT11:een.

Vaiheittainen vaihtosäännön luominen käyttämällä "Data Conversion" -kokoonpanoa (metadata on ladattava):

1) Luo tätä varten sääntö objektin lataamista varten, siirry "Tietojen lataussäännöt" -välilehteen ja napsauta Lisää. Valitse näyttöön tulevasta ikkunasta malliobjekti, joka on itsetilirekisteri. Muutamme näytteenottomenetelmän mielivaltaiseksi algoritmiksi.

2) Siirrytään itse koodin kirjoittamiseen, koska UT:ssa ei ole itselaskentarekisteriä, joten se on muunnettava. Ensin tarvitsemme kyselyn, joka palauttaa parametriemme mukaan saldot keskinäisille selvityksille. "Ennen käsittelyä" -tapahtumakäsittelijään kirjoitamme seuraavan pyynnön:

QueryText = "VALITSE
| Omavaraiset saldot. Tili,
| Itsekantavat Balances.Subconto1 AS Subconto1,
| ISNULL(SUM(Self-AccountingRemaining.RemainingDt),0) AS MääräJäljelläDt,
| ISNULL(SUM(Self-AccountingRemaining.RemainingCt),0) AS AmountRemainingCt,
| MAKSIMI(kustannuslaskennan saldot.alitili2.pvm) AS Selvitysasiakirjan päivämäärä,
| MAKSIMI(Itsekirjanpidon saldot. Alatili2.Numero) AS-kirjanpitotositteen numero
|FROM
| Kirjanpitorekisteri Omavaraiset saldot (&OnDate, Tili = &tili).
| MISSÄ
<>&ryhmä ja
| Omavaraiset saldot 1. Emotili<>&ryhmä1
|GROUP BY
| Omavaraiset saldot. Tili,
| Omavaraiset saldot Alatili 1,
| Self-supportingRemains.Subconto2
|TILAUS
| Subconto1
|AUTOTILAUS";

Tehtäväni oli rajoittaa vastapuoliryhmiä, joille keskinäiset selvitykset ladataan.

Määritämme muuttujien arvot, joita käytetään tulevaisuudessa.

OnDate = päivämäärä("20130101");
TD = NykyinenPäiväys();
group = Directories.Counterparties.FindByName("Ostajat");
group1 = Hakemistot.Counterparties.FindByName("Palautukset YKSILÖILLE");

Luomme taulukon, jonka siirrämme myöhemmin arvon muunnossääntöön.

TZ = Uusi arvotaulukko();
TK.Columns.Add("Vastapuoli");
TK.Columns.Add("Summa");
TK.Columns.Add("AmountREGLE");
TK.Columns.Add("Laskentaasiakirja");
TK.Columns.Add("Sovitusasiakirjan päivämäärä");
TK.Columns.Add("Selvitysasiakirjan numero");
TK.Columns.Add("Kumppani");
TK.Columns.Add("Keskinäisen selvityksen valuutta");
TK.Columns.Add("Maksupäivä");

Asetamme parametrit, soitamme pyynnön, täytämme taulukon ja kutsumme muunnossäännön.

request = new Request(RequestText);
request.SetParameter("ryhmä", ryhmä); request.SetParameter("ryhmä1",ryhmä1);
request.SetParameter("Päivämäärä",Päivämäärä);
request.SetParameter("Tili", Tilikaaviot. Oma kirjanpito. Laskelmat muiden toimittajien ja urakoitsijoiden kanssa);//76.05
Hae = request.Run().Select();
TZ.clear();
Kun Select.Next() Loop
jos Sample.SumRemainingCT = 0 tai Sample.SumRemainingCT = "" niin
jatkaa;
loppu Jos;
jos Sample.AmountRemainderCT< 0тогда
report(""+Sample.Subconto1+" negatiivinen arvo "+Sample.SumRemainingCT);
loppu Jos;
LineTZ = TZ.Lisää();
LineTZ.Counterparty = Selection.Subconto1;
LineTZ.sum = Selection.SumRemainingCT;//Selection.SumRemainingCT;
LineTZ.sumRegl = Sampling.SumRemainingCT;//Sampling.SumRemainingCT;
Rivi TK.Calculation Document Date = Selection.Calculation Document Date;
Rivi TK.Calculation Document Number = Selection.Calculation Document Number;
LineTZ.PaymentDate = TD;
EndCycle;
OutData = Uusi rakenne;
OutgoingData.Insert("Päiväys", CurrentDate());
OutgoingData.Insert("CalculationsWithPartners", TK);
OutgoingData.Insert("Toimenpidetyyppi", "Velkasaldot toimittajille");
OutgoingData.Insert("Kommentti", "Luotu tilisaldolle 76.05");
report("76.05 LUOTTO-aloitus");
UploadByRule(, OutgoingData, "Saldojen syöttö keskinäistä selvitystä varten_7605Credit");

Suoritamme saman toimenpiteen myös muille tarpeellisille tileille (niiden kuvaus sekä valmis sääntö on liitteenä).

3) Siirrytään objektin muunnossääntöjen luomiseen avaamalla "Objektimuunnossäännöt" -välilehti. Lisätään sinne uusi sääntö nimeltä "Input Balances By Mutual Settlement_7605Credit", jätetään lähdeobjekti tyhjäksi, asetetaan vastaanottajaobjektiksi dokumentti "Enter Balances" ja poistetaan asetusvälilehdeltä lippu "Hae vastaanottajaobjektia lähdeobjektin sisäinen tunniste".

"Ennen lataamista" -tapahtumakäsittelijään kirjoitamme seuraavan koodin:

GenerateNewNumberOrCodeIfNotSpecified = tosi;

"Latauksen jälkeen" -tapahtumakäsittelijässä kirjoitamme:

execute(algoritms.AfterLoadInputRemainings);

se suorittaa seuraavan sisällön sisältävän algoritmin:

valuutta = Constants.RegulatedAccountingCurrency.Get();
object.Owner = SessionParameters.CurrentUser;
objekti.organisaatio=parametrit.organisaatio;
jokaiselle object.calculationspartners-silmukan sivulle
Page.SettlementDocument = Directories.Counterparty Agreements.empty link();
PageCurrencySettlements = valuutta;
jos ValueFilled(sivu.vastapuoli.kumppani) sitten
p.partner = p.counterparty.partner;
muuten
kumppanit = Directories.Partners.FindByName(sivu.vastapuoli.Nimi);
jos työpöytä<>Undefined ja työpöydät<>Directories.Partners.emptylink() sitten
p.partner = työpöytä;

objekti2.Kumppani = työpöytä;
objekti2.Kirjoita();
muuten
suorita(algoritmit.AddPartner);
loppu Jos;

loppu Jos;

syklin loppu;

Tämä algoritmi suoritetaan vastaanottimen puolella (BP). Keskinäisten selvitysten saldonsiirron lisäksi tehtävänä on siirtää vastapuolia, mutta UT käyttää kumppaneita, joten tarkistamme asiakirjan luomisen jälkeen, ovatko kaikki vastapuolet ja kumppanit vastaanottajatietokannassa, jos niitä ei jostain syystä ole , sitten lisäämme ne.

Urakoitsijoiden lisääminen ottaa käyttöön muunnossäännön "Vastapuolet"-hakemistoon. Voit luoda sen samalla tavalla kuin edellinen sääntö, mutta antaa järjestelmän verrata tarvittavia kenttiä.

Kumppaneille luotiin algoritmi, joka suoritetaan vastaanottajan puolella.

Algoritmin suorittamiseksi vastaanottimen puolella sinun on tarkistettava algoritmiikkunan oikeassa yläkulmassa oleva "Ladattaessa käytetty" -merkki (muokatessasi sitä).

Alla on "Lisää kumppani" -algoritmin koodi:

nPartner = Directories.Partners.CreateItem();
nPartner.Nimi = sivu.vastapuoli.nimi;
nPartner.Comment = "Luotu BP:stä ladattaessa";
nPartner.NameFull = sivu.counterparty.NameFull;
nPartner.Supplier = ?(find(sivu.vastapuoli.Lisätiedot,"Toimittaja")>0,true,false);
nPartner.Client = ?(find(page.counterparty.AdditionalInformation,"Asiakas")>0,tosi,epätosi);
OtherRelations = ?(find(page.counterparty.AdditionalInformation,"Other")>0,true,false);
npartner.Write();
p.partner = npartner.link;
vastapuoli = Directories.Counterparties.FindByName(sivu.vastapuoli.Nimi);
objekti2 = vastapuoli.GetObject();
objekti2.Kumppani = npartner.link;
objekti2.Kirjoita();

Palataan objektin muunnossääntöön. Nyt meidän on määritettävä vastaavuus lähde- ja kohdekenttien välillä, tämä olisi voitu tehdä juuri ennen koodin kirjoittamista. Kenttien vertailua varten alemmassa taulukkoosassa on painike "Ominaisuuksien synkronointi" ohjatun toiminnon kutsumiseksi. Tässä ohjatussa toiminnossa voimme joko kartoittaa kentät tai jättää ne ilman lähdettä ja kohdetta. Meidän tapauksessamme jätämme kaikki kentät ja PM:t ilman lähdettä.

Kun vaaditut kentät on valittu alemmasta TC:stä, asetamme kullekin kenttään lipun "Hae saapuvista tiedoista" -sarakkeeseen. Tämä lippu osoittaa, että järjestelmä etsii tätä kenttää saapuvista tiedoista. On tärkeää, että kentän nimi vastaa saapuvien tietojen nimeä, muuten näyttöön tulee viesti, jonka mukaan kenttää ei löydy.

Teksti ei kuvaa kaikkia prosessin vivahteita.

Tietojen siirtäminen eri kokoonpanojen välillä ei ole triviaali tehtävä. Kuten aina, ratkaisuja on useita, mutta kaikki eivät ole optimaalisia. Yritetään ymmärtää tiedonsiirron vivahteet ja valita universaali strategia tällaisten ongelmien ratkaisemiseksi.

Tietojen siirron ongelma (puhumme puhtaasti 1C-yhtiön tuotteista) ratkaisusta toiseen ei ilmennyt eilen. 1C-yritys ymmärtää erittäin hyvin, mitä vaikeuksia kehittäjät kohtaavat siirtojen luomisessa, joten se yrittää kaikin mahdollisin tavoin auttaa työkaluilla.

Alustan kehittämisen aikana yritys esitteli useita universaaleja työkaluja sekä tiedonsiirtoa yksinkertaistavia teknologioita. Ne on sisäänrakennettu kaikkiin vakioratkaisuihin, ja identtisten kokoonpanojen välisten siirtymien ongelma on yleensä ratkaistu. Voiton vahvistaa jälleen standardiratkaisujen tiivis integrointi.

Epästandardisten ratkaisujen välisten siirtymien myötä tilanne on hieman monimutkaisempi. Laaja valikoima tekniikoita antaa kehittäjille mahdollisuuden valita itsenäisesti optimaalisen tavan ratkaista ongelma heidän näkökulmastaan.

Katsotaanpa joitain niistä:

  • vaihto tekstitiedostojen kautta;
  • vaihtosuunnitelmien käyttö;
  • jne.

Jokaisella niistä on omat hyvät ja huonot puolensa. Yhteenvetona voidaan todeta, että suurin haitta on sen monisanaisuus. Siirtoalgoritmien itsenäinen toteutus vaatii huomattavia aikakustannuksia sekä pitkän virheenkorjausprosessin. En edes halua puhua lisätuesta sellaisille päätöksille.

Tuen monimutkaisuus ja korkeat kustannukset saivat 1C-yrityksen luomaan universaalin ratkaisun. Tekniikat, jotka mahdollistavat muuttoliikkeen kehittämisen ja tukemisen yksinkertaistamisen mahdollisimman paljon. Tämän seurauksena idea toteutettiin erillisen konfiguraation muodossa - "Data Conversion".

Tietojen muuntaminen - vakioratkaisu, itsenäinen konfigurointi. Jokainen käyttäjä, jolla on ITS:Prof-tilaus, voi ladata tämän paketin täysin ilmaiseksi käyttäjätukisivustolta tai ITS-levyltä. Asennus suoritetaan normaalilla tavalla - kuten kaikki muutkin 1C:n standardiratkaisut.

Nyt vähän ratkaisun eduista. Aloitetaan tärkeimmästä - monipuolisuudesta. Ratkaisua ei ole räätälöity tiettyihin alustakokoonpanoihin/versioihin. Se toimii yhtä hyvin sekä vakio- että mukautettujen kokoonpanojen kanssa. Kehittäjillä on universaali tekniikka ja standardoitu lähestymistapa uusien migraatioiden luomiseen. Ratkaisun monipuolisuuden ansiosta voit valmistella migraatioita myös muille alustoille kuin 1C:Enterprise.

Toinen iso plussa on visuaaliset apuvälineet. Yksinkertaiset siirrot luodaan ilman ohjelmointia. Kyllä, kyllä, ilman yhtä koodiriviä! Pelkästään tästä syystä kannattaa käyttää aikaa tekniikan oppimiseen kerran ja sitten käyttää arvokkaita taitoja toistuvasti.

Kolmas etu, jonka haluaisin huomauttaa, on tietojen jakelua koskevien rajoitusten puuttuminen. Kehittäjä itse valitsee tavan toimittaa tiedot vastaanottimen kokoonpanoon. Käytettävissä on kaksi vaihtoehtoa: lataaminen xml-tiedostoon ja suora yhteys tietokantaan (COM/OLE).

Opiskele arkkitehtuuria

Tiedämme jo, että tietojen muuntaminen voi tehdä ihmeitä, mutta ei ole vielä täysin selvää, mitkä ovat tekniset edut. Ensimmäinen asia, joka sinun on ymmärrettävä, on, että kaikki tiedonsiirto (muunnos) perustuu vaihtosääntöihin. Exchange-säännöt ovat tavallinen xml-tiedosto, joka kuvaa rakennetta, johon tietoturvan tiedot ladataan. Palvelun käsittely, joka lataa/lataa dataa, analysoi vaihtosäännöt ja suorittaa latauksen niiden perusteella. Latauksen aikana tapahtuu käänteinen prosessi.

“CD”-konfiguraatio on eräänlainen visuaalinen konstruktori, jonka avulla kehittäjä luo vaihtosääntöjä. Se ei osaa ladata tietoja. Tästä vastaa CD-jakelupakettiin sisältyvä ulkoinen lisäpalvelukäsittely. Niitä on useita (XX tiedostonimessä on alustan versionumero):

  • MDXXExp.epf- käsittelyn avulla voit ladata kuvauksen tietokantarakenteesta xml-tiedostoon. Rakennekuvaus ladataan CD:lle lisäanalyysiä ja vaihtosääntöjen luomista varten.
  • V8ExchanXX.epf- lataa/lataa tietoja tietokannasta vaihtosääntöjen mukaisesti. Tyypillisissä kokoonpanoissa käsittely on valmiina (katso "Palvelu"-valikkokohta). Käsittely on universaalia, eikä se ole sidottu mihinkään tiettyyn kokoonpanoon/sääntöön.

Okei, määritellään nyt kaiken yllä olevan perusteella uuden konversion kehittämisen vaiheet:

  1. Tehtävän määritelmä. On tarpeen ymmärtää selvästi, mitä tietoja on siirrettävä (mistä konfiguraatioobjekteista) ja mikä tärkeintä, mihin se siirretään.
  2. Konfigurointirakenteiden kuvausten (Source/Sink) valmistelu myöhempää CD-levylle lataamista varten. Ongelma on ratkaistu palvelukäsittelyllä MDXXExp.epf.
  3. Valmiiden rakennekuvausten lataaminen tietoturvaan.
  4. Vaihtosääntöjen luominen visuaalisen CD-työkalun avulla.
  5. Suoritetaan lataus/lataus luotujen tietojen muunnossääntöjen mukaisesti käyttämällä V8ExchanXX.epf-käsittelyä.
  6. Virheenkorjaus vaihtosäännöt (tarvittaessa).

Yksinkertaisin muunnos

Demonstraatiota varten tarvitsemme kaksi käyttöön otettua kokoonpanoa. Päätin valita vaihtoehdon: "Trade Management" 10. painos ja pieni kotikirjoitettu ratkaisu. Tehtävänä on siirtää tietoja "UT"-standardista. Nimetään lyhyyden vuoksi itse kirjoitettua ratkaisua "Sink" ja kaupan hallintaa "lähde". Aloitetaan ongelman ratkaiseminen siirtämällä elementtejä "Nomenclature"-hakemistosta.

Ensinnäkin tarkastellaan tietojen muunnosjärjestelmää ja luetaan uudelleen luettelo toiminnoista, jotka on tehtävä. Sitten käynnistämme "Source"-kokoonpanon ja avaamme siinä MD82Exp.epf-palvelunkäsittelyn.

Käsittelyliittymässä ei ole runsaasti asetuksia. Käyttäjän tarvitsee vain ilmoittaa metatieto-objektien tyypit, joita ei sisällytetä rakenteen kuvaukseen. Useimmissa tapauksissa näitä asetuksia ei tarvitse muuttaa, koska Ei ole erityistä järkeä purkaa liikkeitä akkumulaatiorekistereillä (esimerkiksi).

On oikeampaa muodostaa liike pitäen asiakirjoja vastaanottimessa. Siirron jälkeen asiakirja tekee kaikki liikkeet itse. Toinen argumentti oletusasetusten puolustamiseksi on tiedostokoon pienentäminen lataamisen yhteydessä.

Jotkut asiakirjat (erityisesti vakiokokoonpanoissa) luovat siirtoja useiden rekistereiden välillä. Kaiken tämän sisällön purkaminen tekee tuloksena olevasta XML-tiedostosta liian suuren. Tämä voi vaikeuttaa myöhempää kuljetusta ja lataamista vastaanottimen alustaan. Mitä suurempi tiedosto on, sitä enemmän RAM-muistia tarvitaan sen käsittelemiseen. Harjoitteluni aikana minulla oli mahdollisuus kohdata kohtuuttoman suuria lataustiedostoja. Tällaiset tiedostot kieltäytyivät täysin jäsentämästä tavallisilla työkaluilla.

Joten jätämme kaikki oletusasetukset ja lataamme kokoonpanon kuvauksen tiedostoon. Toistamme samanlaisen menettelyn toiselle pohjalle.

Avaa CD ja valitse päävalikosta "Hakemistot" -> "Asetukset". Hakemisto tallentaa kuvaukset kaikkien konfiguraatioiden rakenteista, joita voidaan käyttää muunnoksissa. Lataamme kokoonpanon kuvauksen kerran, jonka jälkeen voimme käyttää sitä useita kertoja erilaisten muunnosten luomiseen.

Napsauta hakemistoikkunassa painiketta " Lisätä” ja valitse näkyviin tulevasta ikkunasta kokoonpanoa kuvaava tiedosto. Valitse "Lataa uuteen kokoonpanoon" -valintaruutu ja napsauta "Lataa" -painiketta. Suoritamme samanlaisia ​​​​toimia toisen kokoonpanon rakenteen kuvauksen kanssa.

Nyt olet valmis luomaan vaihtosääntöjä. Valitse CD-päävalikosta "Hakemistot" -> "Konversiot". Lisää uusi elementti. Uuden muunnoksen luomisikkunassa sinun on määritettävä: lähdemääritys (valitse UT) ja kohdemääritys (valitse "Vastaanotin"). Avaa seuraavaksi "Lisäasetukset"-välilehti ja täytä seuraavat kentät:

  • Exchange säännöt -tiedoston nimi - luodut vaihtosäännöt tallennetaan tällä nimellä. Voit muuttaa tiedoston nimeä milloin tahansa, mutta on parasta määrittää se nyt. Tämä säästää aikaa tulevaisuudessa. Nimesin demoesimerkin säännöt: "rules-ut-to-priemnik.xml".
  • nimi - muunnoksen nimi. Nimi voi olla mitä tahansa, rajoitin itseni "Demo. UT vastaanottajalle."

Siinä kaikki, napsauta "OK". Välittömästi eteen ilmestyy ikkuna, joka pyytää meitä luomaan kaikki säännöt automaattisesti. Tällaisen houkuttelevan tarjouksen hyväksyminen antaa isännälle komennon analysoida automaattisesti valittujen kokoonpanojen kuvaukset ja luoda itsenäisesti vaihtosäännöt.

Merkitään "i" heti. Ohjattu toiminto ei pysty luomaan mitään vakavaa. Tätä mahdollisuutta ei kuitenkaan pidä jättää huomiotta. Jos on tarpeen luoda vaihto identtisten kokoonpanojen välillä, asiantuntijan palvelut ovat erittäin hyödyllisiä. Esimerkiksi manuaalinen tila on parempi.

Katsotaanpa tarkemmin "Exchange Rules Settings" -ikkunaa. Käyttöliittymä voi tuntua hieman hämmentävältä - suuri määrä välilehtiä täynnä säätimiä. Itse asiassa kaikki ei ole niin vaikeaa, alat tottua tähän hulluun muutaman tunnin työskentelyn jälkeen.

Tässä vaiheessa olemme kiinnostuneita kahdesta välilehdestä: "Objektimuunnossäännöt" ja "Datan lataussäännöt". Aluksi meidän on konfiguroitava täsmäyssäännöt, ts. vertailla kahden kokoonpanon kohteita. Toiseksi määritä mahdolliset objektit, jotka ovat käyttäjän saatavilla ladattavaksi.

"Objektin muunnossäännöt" -välilehden toisessa puoliskossa on lisäpaneeli, jossa on kaksi välilehteä: "Ominaisuuden muuntaminen" ja " Muunnetaan arvoja" Ensimmäinen valitsee valitun objektin ominaisuudet (yksityiskohdat), ja toinen on tarpeen ennalta määritettyjen arvojen (esimerkiksi ennalta määritettyjen hakemistoelementtien tai luetteloelementtien) kanssa työskentelemiseen.

Hienoa, nyt luodaan muunnossääntöjä hakemistoille. Voit suorittaa tämän toiminnon kahdella tavalla: käytä ohjattua objektin synkronointitoimintoa (""-painike) tai lisää vastaavuus jokaiselle objektille manuaalisesti.

Käytämme ensimmäistä vaihtoehtoa tilan säästämiseksi. Poista ohjatun toiminnon ikkunassa valinta ryhmän " Dokumentointi" (olemme kiinnostuneita vain hakemistoista) ja laajentaa ryhmää" Hakemistot" Selaamme luetteloa huolellisesti ja katsomme vertailukelpoisten hakuteosten nimiä.

Minun tapauksessani tällaisia ​​hakemistoja on kolme: Nimikkeistö, Organisaatiot ja Varastot. Siellä on myös Clients-niminen hakemisto, joka palvelee samaa tarkoitusta kuin " Vastapuolet"määrityksestä" UT" Totta, mestari ei voinut verrata niitä erilaisten nimien vuoksi.

Voimme korjata tämän ongelman itse. Löydämme ikkunasta " Objektiottelut" hakuteos " Asiakkaat" ja valitse "Lähde"-sarakkeesta "Vastapuolet"-hakemisto. Valitse sitten "Tyyppi" -sarakkeen ruutu ja napsauta "OK" -painiketta.

Ohjattu objektin synkronointitoiminto tarjoaa automaattisesti sääntöjen luomisen kaikkien valittujen objektien ominaisuuksien muuntamiseksi. Kiinteistöjä verrataan nimellä ja tämä riittää esittelyyn, olemme samaa mieltä. Seuraava kysymys on ehdotus purkamissääntöjen luomiseksi. Hyväksytään sekin.

Vaihtosääntöjen pohja on valmis. Valitsimme synkronoitavat objektit, ja ominaisuuksien muuntamisen säännöt ja lataussäännöt luotiin automaattisesti. Tallennetaan vaihtosäännöt tiedostoon, avataan sitten IB "lähde" ​​(minun tapauksessani se on UT) ja käynnistetään palvelun käsittely siinä V8Exchan82.epf.

Ensinnäkin, valitse käsittelyikkunassa luomamme vaihtosäännöt. Vastaamme kysymykseen lastaussäännöistä myöntävästi. Käsittely analysoi vaihtosäännöt ja rakentaa puun samannimistä kohteista, jotka ovat ladattavissa. Tätä puuta varten voimme asettaa kaikenlaisia ​​valintoja tai vaihtaa solmuja, joita muuttamalla meidän on valittava tietoja. Haluamme ladata ehdottomasti kaikki tiedot, joten suodattimia ei tarvitse asentaa.

Kun olet ladannut tiedot tiedostoon, siirry kohtaan IB " Vastaanotin" Avaamme siinä myös käsittelyn V8Exchan82.epf, vain tällä kertaa siirrymme "Tietojen lataus" -välilehteen. Valitse tiedosto ja napsauta "Lataa" -painiketta. Siinä kaikki, tiedot on siirretty onnistuneesti.

Todellisen maailman ongelmia

Ensimmäinen demo voi olla harhaanjohtava. Kaikki näyttää melko yksinkertaiselta ja loogiselta. Itse asiassa tämä ei ole totta. Todellisessa työssä syntyy ongelmia, joita on vaikea tai täysin mahdoton ratkaista pelkillä visuaalisilla keinoilla (ilman ohjelmointia).

Jotta en joutuisi pettymään tekniikkaan, valmistelin useita tosielämän ongelmia. Tulet varmasti törmäämään niihin töissä. Ne eivät näytä niin triviaaleilta ja saavat sinut katsomaan tietojen muuntamista uudesta näkökulmasta. Harkitse esitettyjä esimerkkejä huolellisesti ja käytä niitä katkelmina todellisten ongelmien ratkaisemisessa.

Tehtävä nro 1. Täytä puuttuvat tiedot

Oletetaan, että meidän on siirrettävä hakemisto " Vastapuolet" Vastaanottimessa on samanlainen asiakashakemisto tätä tarkoitusta varten. Se soveltuu täysin tietojen tallentamiseen, mutta siinä on rekvisiitta " Organisaatio”, jonka avulla voit erottaa vastapuolet kuulumalla organisaatioon. Oletusarvoisesti kaikkien vastapuolten on kuuluttava nykyiseen organisaatioon (tämä saadaan samannimisestä vakiosta).

Ongelmaan on useita ratkaisuja. Harkitsemme mahdollisuutta täyttää tiedot " Organisaatio"oikein tietokannassa" Vastaanotin”, eli tietojen latauksen yhteydessä. Nykyinen organisaatio on tallennettu vakioon, joten tämän arvon saamiselle ei ole esteitä. Avataan objektin muunnossääntö (jäljempänä PKO) " Asiakkaat” (kaksoisnapsauta objektia) ja siirry ohjatun sääntöjen asennustoiminnon ”Tapahtumankäsittelijät” -osioon. Käsittelijöiden luettelosta löydät " Latauksen jälkeen”.

Kuvataan koodi nykyisen organisaation hankkimiseksi ja sen liittämiseksi yksityiskohtiin. Kun "Latauksen jälkeen" -käsittelijä käynnistetään, objekti on täysin muodostettu, mutta sitä ei vielä kirjoiteta tietokantaan. Kukaan ei kiellä meitä muuttamasta sitä harkintamme mukaan:

Jos EI Object.ThisGroup sitten Object.Organization = Constants.CurrentOrganization.Get(); loppu Jos;

Ennen kuin täytät tiedot" Organisaatio"On tarpeen tarkistaa määritteen arvo" Tämä ryhmä" Hakukirjaan " Asiakkaat"Hierarkinen ominaisuus on asetettu, joten ryhmän tarkistaminen on välttämätöntä. Täytä kaikki tiedot samalla tavalla. Muista lukea muiden käsittelijän vaihtoehtojen ohje " Latauksen jälkeen" Esimerkiksi niiden joukossa on parametri " Epääminen" Jos annat sille arvon "True", objektia ei kirjoiteta tietokantaan. Siten on mahdollista rajoittaa niitä objekteja, jotka voidaan kirjoittaa lataushetkellä.

Tehtävä nro 2. Tarkemmat tiedot tietorekisterissä

Hakemistossa " Vastapuolet"UT-kokoonpanot, tiedot saatavilla" Ostaja"ja" Palveluntarjoaja" Molemmat tiedot ovat tyyppiä " Boolean” ja niitä käytetään vastapuolen tyypin määrittämiseen. IB:ssä" Vastaanotin", hakemistossa " Asiakkaat"Ei ole samanlaisia ​​tietoja, mutta tietorekisteri on olemassa" Asiakastyypit" Se suorittaa samanlaisen toiminnon ja voi tallentaa useita määritteitä yhdelle asiakkaalle. Tehtävämme on siirtää tietojen arvot erillisiksi merkinnöiksi tietorekisteriin.

Valitettavasti pelkät visuaaliset keinot eivät kestä tässäkään. Aloitetaan pienestä, luodaan tietorekisteriin uusi ohjelmisto" Asiakastyypit" Älä mainitse lähteenä mitään. Vältä automaattista lataussääntöjen luomista.

Seuraava vaihe on lataussääntöjen luominen. Siirry sopivaan välilehteen ja napsauta " Lisätä" Täytä lataussääntöjen lisäysikkunassa:

  • Näytteenottomenetelmä. Vaihda kohtaan "Mielivaltainen algoritmi";
  • Muunnossääntö. Valitse tietorekisteri "Asiakastyypit";
  • Säännön koodi (nimi). Kirjoita se muistiin nimellä "Ladataan asiakastyyppejä";

Nyt sinun on kirjoitettava koodi valitaksesi ladattavat tiedot. Parametri " Datan otanta" Voimme sijoittaa kokoelman, jossa on valmis tietojoukko. Parametri " Datan otanta” voi ottaa erilaisia ​​arvoja - kyselyn tulos, valinta, arvokokoelmat jne. Alustamme sen arvotaulukoksi, jossa on kaksi saraketta: asiakas ja asiakastyyppi.

Alla on tapahtumakäsittelijän koodi " Ennen käsittelyä" Se alustaa parametrin " Datan otanta" ja sen jälkeen tietojen täyttäminen hakemistosta" Vastapuolet" Tässä sinun tulee kiinnittää huomiota sarakkeen täyttämiseen " Asiakastyyppi" "UT":ssa attribuuttimme ovat "Boolean"-tyyppiä, ja vastaanottaja on luettelo.

Tässä vaiheessa emme voi muuntaa niitä vaadittuun tyyppiin (se ei ole UT:ssa), joten jätämme ne toistaiseksi merkkijonojen muotoon. Sinun ei tarvitse tehdä tätä, mutta haluan heti näyttää, kuinka suoratoistaa lähteestä puuttuvaan tyyppiin.

DataFetch = Uusi arvotaulukko(); DataSelection.Columns.Add("Asiakas"); DataSelection.Columns.Add("ClientType"); SelectingDataFromDirectory = Hakemistot.Accounts.Select(); Kun valitset tietoja hakemistosta.Seuraava() -silmukka, jos valitset tietoja hakemistosta.Tämä ryhmä, sitten jatka; loppu Jos; Jos tietojen valinta hakemistosta.ostaja, sitten NewRow = Data Selection.Add(); NewRow.Client = DataFetchFromDirectory.Link; NewRow.ClientType = "Asiakas"; loppu Jos; Jos DataFetchFromDirectory.Supplier Then NewRow = DataFetch.Add(); NewRow.Client = DataFetchFromDirectory.Link; NewString.ClientType = "Toimittaja"; loppu Jos; EndCycle;

Tallennetaan tietojen lataussääntö ja palataan "-välilehdelle Objektin muunnossäännöt" Lisätään tietorekisteriin " Asiakastyypit” omaisuuden muunnossäännöt: asiakas ja asiakastyyppi. Jätetään lähde tyhjäksi, ja "Ennen purkamista" -tapahtumakäsittelijään kirjoitamme:

//Asiakas-ominaisuuden kohdalla Arvo = Source.Client; //Ominaisuus "ClientType" If Source.Client = "Buyer" Then Expression = "Enumerations.ClientTypes.Buyer" ElseIf Source.Client = "Supplier" Then Expression = "Enumerations.ClientTypes.Supplier"; loppu Jos;

Listauksessa tiedot täytetään valitun tietonäytteen perusteella. Välitämme asiakkaan vain linkkinä ja kirjoitamme asiakkaan tyypin parametriin " Ilmaisu" Tämän parametrin tiedot tulkitaan vastaanottimessa, ja kun se suoritetaan, potkuri täytetään oikealla luettelon arvolla.

Siinä kaikki, vaihtosäännöt ovat valmiit. Tarkastelun esimerkki osoittautui melko yleismaailmalliseksi. Samanlaista lähestymistapaa käytetään usein siirrettäessä tietoja 7.7-alustalla luoduista kokoonpanoista. Silmiinpistävä esimerkki tästä on säännöllisten yksityiskohtien siirtäminen.

Tehtävä nro 3. Temppuja pöydän osien kanssa

Usein törmäät tehtäviin, jotka edellyttävät rivien kirjaamista yhdestä taulukon osasta useisiin. Esimerkiksi alkukokoonpanossa palvelut ja tavarat rekisteröidään yhteen taulukkoosaan, ja vastaanottimessa näiden entiteettien tallennus on erotettu. Jälleen, ongelmaa ei voida ratkaista visuaalisilla keinoilla. Tässä on kätevää ottaa perustana toisen ongelman ratkaisu.

Teemme tietojen purkamissäännön, määritämme mielivaltaisen algoritmin ja "Ennen purkamista" -käsittelijään kirjoitamme pyynnön saada tiedot taulukkoosasta.

Tilan säästämiseksi en anna pyynnön koodia (voit aina viitata lähteisiin) - siinä ei ole mitään epätavallista. Lajittelemme tuloksena olevan valinnan ja asetamme lajitellut tulokset jo tuttuihin parametreihin " Datan otanta" On jälleen kätevää käyttää arvotaulukkoa kokoelmana:

DataFetch = Uusi arvotaulukko(); //Tässä on toinen taulukko-osa Data Selection.Columns.Add("Tuotteet"); //Tässä on myös taulukkoosa Data Selection.Columns.Add("Palvelut"); SelectionData.Columns.Add("Linkki");

Tehtävä nro 4. Tietojen siirtäminen toimintoon

Jos organisaatio käyttää useita kirjanpitojärjestelmiä, on ennemmin tai myöhemmin tarve siirtää tietoja myöhempien tapahtumien luomisen yhteydessä.

Konfiguraatiossa " BP"On olemassa universaali asiakirja" Operaatio” ja se on ihanteellinen useiden lankojen muodostamiseen. On vain yksi ongelma - dokumentti on tehty ovelasti, eikä siihen voida siirtää tietoja niin helposti.

Löydät esimerkin tällaisesta muunnoksesta artikkelin lähdekoodista. Koodin määrä osoittautui melko suureksi, joten sitä ei kannata julkaista artikkelin yhteydessä. Haluan vain sanoa, että lataaminen uudelleen käyttää mielivaltaista algoritmia tietojen lähetyssäännöissä.

Tehtävä nro 5. Tietojen synkronointi useiden yksityiskohtien välillä

Olemme jo tarkastelleet useita esimerkkejä, mutta emme ole vielä puhuneet objektien synkronoinnista siirron aikana. Kuvitellaan, että meidän on siirrettävä vastapuolet ja osa niistä on luultavasti vastaanottajatietokannassa. Kuinka siirtää tietoja ja estää kaksoiskappaleiden ilmestyminen? Tässä suhteessa CD tarjoaa useita tapoja synkronoida siirretyt objektit.

Ensimmäinen on yksilöllisen tunnisteen mukaan. Monilla objekteilla on yksilöllinen tunniste, joka takaa taulukon ainutlaatuisuuden. Esimerkiksi hakemistossa " Vastapuolet” ei voi olla kahta elementtiä, joilla on samat tunnisteet. CD tekee laskelmia tälle ja kaikille luoduille PCO:ille, haku tunnisteen perusteella on heti käytössä oletusarvoisesti. PCO:ta luotaessa olisi pitänyt kiinnittää huomiota suurennuslasin kuvaan kohteen nimen vieressä.

Synkronointi yksilöllisen tunnisteen avulla on luotettava menetelmä, mutta se ei ole aina tarkoituksenmukaista. Kun yhdistetään hakemistoja " Vastapuolet” (useita eri järjestelmiä) se ei paljoa auta.

Tällaisissa tapauksissa on oikeampaa synkronoida objektit useiden kriteerien mukaan. On oikeampaa etsiä vastapuolia INN:n, KPP:n tai nimen perusteella tai jakaa haku useaan vaiheeseen.

Tietojen muuntaminen ei rajoita kehittäjää määrittämään hakuehtoja. Katsotaanpa abstraktia esimerkkiä. Oletetaan, että meidän on synkronoitava hakemistot " Vastapuolet” eri tietokannoista. Valmistetaan ohjelmisto ja tarkista objektin muunnossääntöjen asetuksista " Jatka hakukenttien etsimistä, jos vastaanotinobjektia ei löydy tunnisteen perusteella" Tällä toiminnolla määritimme välittömästi kaksi hakuehtoa - yksilöllisen tunnisteen ja mukautettujen kenttien perusteella.

Meillä on oikeus valita kentät itse. Valitsemalla TIN-numeron, KPP-tunnuksen ja nimen, ilmoitamme välittömästi useita hakuehtoja. Mukava? Aivan, mutta tämä ei taaskaan riitä. Entä jos haluamme muuttaa hakuehtoja? Esimerkiksi etsimme ensin TIN+KPP-yhdistelmää, ja jos emme löydä mitään, alamme kokeilla onneamme nimen kanssa.

Tällainen algoritmi voidaan hyvin toteuttaa. Tapahtumankäsittelijässä " Hakukentät”Voimme määrittää jopa 10 hakuehtoa ja jokaiselle niistä määritellä oman hakukenttien kokoonpanonsa:

Jos SearchOptionNumber = 1, SearchPropertyNameString = "TIN, KPP"; OtherIfSearchOptionNumber = 2 ThenSearchPropertyNameString = "Nimi"; loppu Jos;

Ratkaisuja on aina useita

Jokaisella tehtävällä on useita ratkaisuja, eikä tiedonsiirto eri kokoonpanojen välillä ole poikkeus. Jokaisella kehittäjällä on oikeus valita oma ratkaisupolkunsa, mutta jos joudut jatkuvasti kehittämään monimutkaisia ​​tiedonsiirtoja, suosittelen ehdottomasti kiinnittämään huomiota "". Saatat joutua investoimaan resursseja (aikaa) koulutukseen aluksi, mutta ne maksavat enemmän kuin kannattavan ensimmäisessä enemmän tai vähemmän vakavassa projektissa.

Mielestäni 1C-yritys jättää epäoikeudenmukaisesti huomiotta tiedon muuntamisen käytön. Koko tekniikan olemassaolon aikana siitä julkaistiin vain yksi kirja: "1C: Enterprise 8. Data conversion: vaihto sovellusratkaisujen välillä." Kirja on melko vanha (2008), mutta siihen kannattaa silti tutustua.

Alustajen tuntemus on edelleen tarpeen

" on universaali työkalu, mutta jos aiot käyttää sitä tiedonsiirtojen luomiseen 1C: Enterprise 7.7 -alustalle kehitetyistä kokoonpanoista, joudut käyttämään aikaa sisäänrakennetun kielen tutustumiseen. Kielen syntaksi ja ideologia ovat hyvin erilaisia, joten sinun on käytettävä aikaa oppimiseen. Muuten periaate pysyy samana.