Kuinka löytää virhe tietojen siirtämisessä. Virheen löytäminen tiedonsiirrossa Säännöt 1c-objektien muuntamiseen

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 sääntö objektin lataamiseksi, siirry "Tietojen lataamisen sää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:

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 Etsi nimen mukaan ("Palautukset henkilöiltä");

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", Tilikartat. Itselaskenta. Laskelmat muiden toimittajien ja urakoitsijoiden kanssa);//76.05
Hae = request.Run().Select();
TK.clear();
Kun Select.Next() Loop
jos Sample.SumRemainingCT = 0 tai Sample.SumRemainingCT = "" niin
jatkaa;
endif;
jos Sample.AmountRemainderCT< 0тогда
report(""+Sample.Subconto1+" negatiivinen arvo "+Sample.SumRemainingCT);
endif;
LineTZ = TZ.Lisää();
Rivi TK.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", NykyinenPäiväys());
OutgoingData.Insert("CalculationsWithPartners", TK);
OutgoingData.Insert("Toimintotyyppi", "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ö ovat 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ä<>Määrittämätön 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);
endif;

endif;

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.Name = sivu.vastapuoli.nimi;
nPartner.Comment = "Luotu BP:stä ladattaessa";
nPartner.NameFull = sivu.counterparty.NameFull;
nPartner.Supplier = ?(find(sivu.vastapuoli.Lisätiedot,"Toimittaja")>0,tosi,epätosi);
nPartner.Client = ?(find(sivu.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, että kenttää ei löydy.

Teksti ei kuvaa kaikkia prosessin vivahteita.

Tulosta (Ctrl+P)

Käsittelijä Ennen vastaanotettujen tietojen tallentamista

Menettely PKO_<ИмяПКО>_Ennen vastaanotettujen tietojen tallentamista yleisessä moduulissa Exchange Manager Universal Formatin kautta sisältää käsittelijän tekstin Ennen vastaanotettujen tietojen tallentamista tietylle PKO:lle. Käsittelijän teksti voi olla tyhjä. Käytännössä sitä käytetään kuitenkin aina dataa ladattaessa toteuttamaan lisälogiikkaa, joka on suoritettava ennen objektin kirjoittamista tietokantaan. Esimerkiksi pitäisikö muutokset ladata olemassa oleviin tietoturvatietoihin vai ladata ne uutena tietona.

Käsittelijä sisältää seuraavat parametrit;

TiedotB tiedot– Tyyppi – DirectoryObject, DocumentObject. Vastaanotettua dataa vastaava tietokantatietoelementti. Jos vastaavia tietoja ei löydy, tällä parametrilla on arvo Määrittämätön .
Vastaanotetut tiedot– Tyyppi – DirectoryObject tai DocumentObject. Tietoelementti, jonka muodostaa tietojen muuntaminen XDTO. Tallennetaan, jos nämä tiedot ovat uusia tietokannassa (IB Data -parametri sisältää arvon Määrittämätön ). IN muuten Vastaanotetut tiedot korvata TiedotB tiedot(kaikki ominaisuudet alkaen Vastaanotetut tiedot siirretty TiedotB tiedot). Jos tietoturvatietojen normaalia korvaamista vastaanotetuilla tiedoilla ei vaadita, kirjoita oma siirtologiikkasi ja asenna se sitten Vastaanotetut tiedot merkitys Määrittämätön
ConvertingProperties. Tyyppi - Arvotaulukko. Sisältää säännöt nykyisen objektin ominaisuuksien muuntamiseksi, alustettu osana vaihtoistuntoa.
Components Exchange. Rakenne, joka sisältää vaihtokomponentteja: vaihtosäännöt ja vaihtoparametrit. Vaihtokomponenttien alustusmenettely on moduulissa Data ExchangeXDTOServer

Katsotaanpa joitain käytännön esimerkkejä, jotka ratkaisin edistyneessä kokoonpanossa, jotta en muuttaisi tyypillisten 1C-sovellusratkaisujen peruskokoonpanoa.

Älä vaihda löydettyjä esineitä latauksen aikana

Edition 3.0:n objektien muuntamisen säännöissä, toisin kuin versiossa 2.0, ei ole ominaisuutta "Älä vaihda löydettyjä objekteja ladattaessa", minkä ansiosta vastaanottimen tietokannan löydetyt kohteet eivät muutu synkronointikenttien arvolla.

Painoksen 3.0 objektimuunnossäännöissä parametri TiedotB tiedot on arvo määrittelemätön, jos objektia ei löydy. Lisäksi, jos parametri Vastaanotetut tiedot on merkitystä määrittelemätön silloin kun poistutaan ohjaajalta, m ei korvata.

Työnantaja pyysi minua muuttamaan muunnossääntöjä UT 11:n ja BP 3.0:n vakiokonfiguraatioiden välillä siten, että kirjanpidon organisaatio- ja varastohakemiston tietoja ei myydä UT:n kanssa vaihdettaessa. He myivät erityisesti näiden hakemistojen lisätiedot kirjanpitoon aina, kun näiden hakemistojen osia rekisteröitiin UT:ssa lähetettäväksi kirjanpitoon.

Suoritin tämän tehtävän kirjanpidon määrityslaajennuksessa, jotta pääkonfiguraatiota ei muutettu. Ratkaisu on esitetty kuvassa. 1. Jos hakemistoelementti on olemassa (löytyy lähteestä), niin parametri TiedotB tiedot on määritelty ja että kaikki ominaisuudet alkaen Vastaanotetut tiedot EI siirretty TiedotB tiedot pitäisi asentaa Vastaanotetut tiedot merkitys Määrittämätön

Kuva 3 Fragmentti ohjelmakoodi kokoonpanolaajennuksessa

Jos hakemistoobjektia ei löydy, niin parametri TiedotB tiedot asioita Epävarma ja sitten Kutsun menettelyyn ContinueCall jatkaaksesi tapahtumakäsittelijän kutsumista laajennettavista määrityksistä

Älä heijasta asiakirjoja säännellyssä kirjanpidossa

Minua pyydettiin mahdollistamaan, että joitain kaupan hallinnassa syntyviä lähetystositteita 11 ei oteta huomioon kirjanpidossa 3.0. Tätä tarkoitusta varten olen lisännyt toteutusasiakirjaan lisäyksityiskohdan "Älä näytä asiakirjoja säännellyssä kirjanpidossa". Jos lippu on asetettu, tämä asiakirja on merkittävä poistettavaksi vastaanotintietokannassa (BP 3.0). Tämän tehtävän monimutkaisuus johtuu siitä, että yrityksen kirjanpitoosastolla asiakirjoissa ei ole lisätietoja. Päätin käyttää kommenttikenttää. Lähdepuolella (UT 11) lähetettäessä täytän kommentit-attribuutin asianmukaisella merkinnällä ja vastaanottimessa (BP), käsittelijässä, asetan ennen vastaanotetun tiedon tallentamista poistomerkinnän kuvassa 10 esitetyllä tavalla. 2

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 vastaanottoobjektin (eli mihin tiedot siirretään tai kirjoitetaan).

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

Etsi kohdeobjektia lähdeobjektin sisäisen tunnisteen perusteella- lippu, joka määrittää objektien haun V8-alustan versiossa. 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 objektit, 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äyttää nopea haku esine purkamisen ja lastauksen aikana- 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:

Purkamissääntöjen mukaan, jos esine on jo purettu, pura se sellaisenaan
Purkamissääntöjen mukaan, jos esinettä ei purettu, emme pura
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. Toisin sanoen muutokset tietokannassa, jossa kohde luotiin, ovat hajallaan kaikkialla, 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-pöytä kanssa mahdollisia vaihtoehtoja hakukentän asetukset käyttäjälle. Säännön laatija päättää mahdollisia yhdistelmiä hakukentä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.

Tiedetään, että 1C-ohjelmat ovat käteviä ja monitoimityökalu kirjanpidon automaatioon, sopii yrityksille useilla eri toimialoilla ja toimialoilla. 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, kun etsitään virheitä esimerkin avulla siirtämällä tietoja 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. Ne. 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ä jatkotoimenpiteissä. Nyt sinun on toistettava prosessi vaihtoehtoisella latauksella kunkin asiakirjan muunnossäännön kanssa. Ne. 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 Asiakirjat. Latasit kaiken tyyppisiä dokumentteja yksitellen, kävit kaikki paikat yksitellen läpi ja laskit, että virhe ilmenee vain kun lataat esimerkiksi asiakirjoja 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 Vastaanottavassa tietokannassa oleva elementti ei lataudu. 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 tyypillinen kä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 erilaisia tyyppejä esineitä. 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 - tiedonsiirtosää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. Jonossa 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ä. IN tässä tapauksessa tämä kohde on Hitsauskoneen invertteri VDI 160R (Kiinteä omaisuus). Jo sisään tällä hetkellä eroa voi nähdä. Tietojen lataussääntö soitti Jäljelle jääneet materiaalit, jonossa 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 Ensisijainen tarkoittaa 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 siirtyä sen korjaamiseen. 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. Virheilmoitus

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ääritä, 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 suljemme pois tämä asiakirja siirrettyjen kohteiden luettelosta ja purkamisen 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 tilasta hallittu sovellus. Erityisesti tyypillisessä kokoonpanossa Integroitu automaatio versio 1.1 voit työskennellä kummassakin tilassa säännöllinen sovellus, ja hallitussa sovellustilassa tai, kuten he myös sanovat, hallittujen lomakkeiden tilassa. Ensimmäisessä tapauksessa valinnat vakiokä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 1C-tietojen siirron aikana tapahtuneen virheen löytämis- ja poistamisprosessi.

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

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äkään 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 eri 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ä tekniset edut ovat. 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äsittely mahdollistaa tietokannan rakenteen kuvauksen lataamisen xml-tiedostoon. Rakennekuvaus ladataan CD:lle lisäanalyysiä ja vaihtosääntöjen luomista varten.
V8ExchanXX.epf- lataa/lataa tietoja tietokannasta vaihtosääntöjen mukaisesti. Useimmissa vakiokokoonpanoissa prosessointi 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:

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.
Konfigurointirakenteiden kuvausten (Source/Sink) valmistelu myöhempää CD-levylle lataamista varten. Ongelma on ratkaistu palvelukäsittelyllä MDXXExp.epf.
Valmiiden rakennekuvausten lataaminen tietoturvaan.
Vaihtosääntöjen luominen visuaalisen CD-työkalun avulla.
Suoritetaan lataus/lataus luotujen tietojen muunnossääntöjen mukaisesti käyttämällä V8ExchanXX.epf-käsittelyä.
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 puolesta on tiedostokoon pienentäminen lataamisen yhteydessä.

Jotkut asiakirjat (erityisesti vakiokokoonpanoissa) luovat siirtoja useiden rekistereiden välillä. Koko tämän talouden purkaminen tekee tuloksen XML-tiedosto liian iso. Tämä voi vaikeuttaa myöhempää kuljetusta ja lataamista vastaanottimen alustaan. Mitä suurempi tiedosto on, sitä enemmän tarvitset RAM käsittelemään sitä. 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-levy 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 luontiikkunassa 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ä säätimillä täytetyt välilehdet. 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.

"Objektimuunnossäännöt" -välilehden toisessa puoliskossa on lisäpaneeli kahdella välilehdellä: "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öskentelyyn.

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 " Asiakirjat" (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 lataussää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älle puulle voimme asettaa kaikenlaisia valintoja tai vaihtaa solmuja, joita muuttamalla meidän on valittava tiedot. 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 täysin totta. IN todellista työtä Esiin tulee 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 tiedon 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(); endIf;

Ennen kuin täytät tiedot" Organisaatio"On tarpeen tarkistaa määritteen arvo" Tämä on 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" Toimittaja" 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. From automaattinen luominen kieltäytyä purkamissäännöistä.

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 "Asiakastyyppien purkaminen";

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;

endIf; Jos tietojen valinta hakemistosta.ostaja, sitten uusi rivi = Data Selection.Add(); NewRow.Client = DataFetchFromDirectory.Link; Asiakastyypit NewRow.ClientType = "Asiakas";

endIf;

Jos DataFetchFromDirectory.Supplier Then NewRow = DataFetch.Add(); NewRow.Client = DataFetchFromDirectory.Link; NewString.ClientType = "Toimittaja";

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 jaettu. 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" Toiminta” 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 siirrettyjä objekteja.

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, tunnistehaku on oletuksena heti käytössä. PCO:ta luodessasi sinun olisi pitänyt huomata suurennuslasin kuva kohteen nimen vieressä.

Synkronointi yksilöllisen tunnisteen avulla on luotettava menetelmä, mutta se ei ole aina tarkoituksenmukaista. Kun yhdistetään hakemistoja " Vastapuolet”(useita erilaisia järjestelmiä) hän 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 PKO ja tarkista objektin muunnossääntöjen asetuksista " Jatka hakukenttien etsimistä, jos vastaanotinobjektia ei löydy tunnisteen perusteella" Tällä toiminnolla määritimme heti 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. Tapahtumakä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"; endIf;

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 ratkaisunsa, mutta jos sinun on jatkuvasti kehitettävä monimutkaisia tietojen siirtoja, suosittelen 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ä tietojen siirtämiseen 1C:Enterprise 7.7 -alustalle kehitetyistä kokoonpanoista, joudut käyttämään aikaa sisäänrakennetun kielen tuntemiseen. Kielen syntaksi ja ideologia ovat hyvin erilaisia, joten sinun on käytettävä aikaa oppimiseen. Muuten periaate pysyy samana.