Regnskap for kontanttransaksjoner er regulert av instruksjonen fra sentralbanken i Den russiske føderasjonen datert 11. mars 2014 N 3210-U "Om prosedyren for å utføre kontanttransaksjoner av juridiske personer og en forenklet prosedyre for å utføre kontanttransaksjoner av individuelle gründere og små bedrifter." Vi anbefaler at regnskapssjefene, kassererne og andre ansatte i finanstjenesten til foretaket som jobber med kontantdokumenter blir kjent med det uten feil. Det er også verdt å gjøre deg kjent med instruksjonen fra sentralbanken i Den russiske føderasjonen datert 7. oktober 2013 N 3073-U "Om gjennomføring av kontantbetalinger".
Mottakerne av budsjettmidler tar i tillegg hensyn til regelverket om regulering av kontanttransaksjoner i budsjettfinansiering.
Individuelle gründere kan ikke føre oversikt over kontanttransaksjoner i 1C, de bør ikke sette en kontantgrense. Samtidig skal slike dokumenter som KUDR holdes obligatoriske, siden gjelder ikke kassaapparater.
Små bedrifter er ikke forpliktet til å sette en kontantgrense (antall personer er opptil 100 personer og de ferdige inntektene er opptil 800 millioner rubler, inkludert mikrobedrifter - organisasjoner med et antall på opptil 15 personer og inntektene er oppe til 150 millioner rubler). Resten av virksomhetene setter en kontantgrense, etter overskridelse av hvilke kontanter som skal tilbakeføres til banken. Det gjøres unntak for fond som har til formål å betale lønn og lignende utbetalinger. På lønnsutbetalingsdager i inntil 5 virkedager (nøyaktig frist for betaling er satt av bedriftslederen og angitt på lønnslisten), er det tillatt å overskride grensen for kontanter i kassa for beløp beregnet på å betale lønn. for lønn, ytelser og lignende utbetalinger.
Mottak av midler til kasserer behandles Mottar kontantordre(forkortet PKO), betalinger - Kontantbestilling av forbruksvarer(forkortet RSC). For utbetaling av lønn mv. skal være forhåndsformet lønn eller lønn, selv om betalinger gjøres til én person. Dokumentsirkulasjon kan utføres i papir eller elektronisk form. I sistnevnte tilfelle skal dokumenter signeres med elektronisk digital signatur. På slutten av dagen på grunnlag av PKO og RCO dannes en kassebok... Hvis det ikke var noen kontantstrøm i løpet av dagen, er det ikke nødvendig å generere en kassebok for den dagen.
Ultimat grense oppgjør i kontanter mellom motparter under én avtale er 100 000 rubler. Oppgjør med enkeltpersoner gjennomføres uten beløpsbegrensninger.
Midlene mottatt i foretakets kasse gjennom salg av varer, ytelse av tjenester, som forsikringspremier, kan bare brukes til følgende formål:
- Utbetaling av lønn og ytelser;
- Forsikringsutbetalinger fysisk personer som har betalt forsikringspremier penger;
- Betaling for varer, verk, tjenester;
- Kontantuttak på konto;
- Refusjon for varer, arbeider, tjenester tidligere betalt kontant.
For andre formål bør kontanter tas ut av brukskontoen i banken.
Brudd på ordren om å utføre kontanttransaksjoner kan føre til bot (artikkel 15.1 i den russiske føderasjonens administrative kode):
- For en offisiell - fra 4000 til 5000 rubler;
- For en juridisk enhet - fra 40 000 til 50 000 rubler.
Skattemyndighetene i Den russiske føderasjonen er engasjert i å kontrollere riktigheten av gjennomføringen av kontanttransaksjoner (artikkel 23.5 i den russiske føderasjonens administrative kode).
Kontantdokumenter i 1C
Ovennevnte metode for regnskapsføring av kontanttransaksjoner er ikke uttømmende og inneholder de grunnleggende reglene for arbeid med kontanter.
Velge menyelementer Bank og kasse => Kasse => Kassedokumenter
Figur 1. Velge kontantdokumenter
Avhengig av versjonen av programmet, kan menyinnstillingene variere litt, men i alle fall i delen Bank og kasse vil du kunne få tilgang til de viktigste kontantdokumentene - PKO og RCO.
Figur 2. Knapper for å legge inn PKO og RKO
Kvittering for kontantbestilling
I 1C foreslås ti typer PKO, avhengig av operasjonen som innføres. De er som følger:
- Betaling fra kjøper;
- Detaljhandel inntekter;
- Refusjon fra den ansvarlige personen;
- Returer fra leverandør;
- Motta kontanter i banken;
- Opptak av lån fra en motpart;
- Opptak av lån fra en bank;
- tilbakebetaling av lån fra motparten;
- tilbakebetaling av lån av den ansatte;
- Annet sogn.
Figur 3. Varianter av PQS-dokumentet
Navnene på dokumentene gjenspeiler deres essens og har for eksempel passende innstillinger Refusjon fra den ansvarlige personen vil som standard ha korrespondanse med konto 71.
PKO-alternativ Annen ankomst ser ut til å være universell siden lar deg velge hvilken som helst konto fra kontoplanen og utføre enhver operasjon. Men metodologer fra 1C anbefaler å bruke det bare som en siste utvei, med atypiske operasjoner, og prøver om mulig å utføre dokumenter med typer operasjoner nr. 1-9.
Nedenfor er tre alternativer for PKO-inndataskjemaet. Generelle regler - obligatoriske felt er uthevet med rød linje.
Figur 4. PKO - Retur fra ansvarlig person
Kapittel Krav til utskriftsskjemaet kan utvides eller klappes sammen når den trykkes.
Figur 5. PKO - kontanter fra banken. Detaljer om det trykte skjemaet vises
Dersom dokumentet innebærer valg av motpart som ikke er en enkeltperson, er det obligatorisk å fylle ut feltet Kontrakt.
Figur 6. PKO - Betaling fra kjøper
Hvis du trenger å spesifisere mer enn én kontrakt, bruk funksjonen Delt betaling, som lar deg fylle ut data for flere kontrakter. I dette tilfellet, etter å ha valgt en motpart, bør du åpne tabelldelen Betalingsfordeling, velge avtaler og angi beløpene for hver. Totalsummen vil bli reflektert i PQS.
Figur 7. PQS-innstillinger - betaling etter avtale
Feltverdi DDS-artikkel fylt ut fra oppslagsboken. Denne veiledningen lar deg legge til Navn av DDS-artikkelen, men meningen Bevegelsestype ikke tilgjengelig for redigering. Hvis det er for mange titler og du vil gruppere dem i mapper, bør du bruke knappen "Opprett gruppe". Den utfylte feltverdien vil bli tatt i betraktning i fremtiden ved generering av rapporteringsskjema nr. 4 "Kontantstrømoppstilling".
Figur 8. Katalog - kontantstrømposter
Fyll ut PKO for mottak av kontanter fra banken.
Figur 9. Et eksempel på en fullført PQS
Figur 10. Oppslag etter PKO
Det skal bemerkes at i dette tilfellet gjenspeiles bevegelsen av penger ikke bare i kontanter, men også i brukskontoen. For å unngå dobbel debitering av penger fra bankkontoen, er transaksjoner av typen Dt 50.01 - Kt 51 dannet av kontanter, ikke bankdokumenter.
Kontokontantordre
En utgående kontantordre, eller kontantoppgjør, dannes på mange måter etter samme regler som PKO. I 1C er det følgende typer kontanthåndteringstjenester:
- Betaling til leverandør
- Gå tilbake til kjøper
- Utstedelse til en ansvarlig person
- Utbetaling av lønn i henhold til oppgave
- Utbetaling av lønn til en ansatt
- Betaling til en ansatt i henhold til en arbeidskontrakt
- Kontantinnskudd til banken
- Nedbetaling av lån til motpart
- Nedbetaling av lån til banken
- Utstedelse av lån til motpart
- Kontantinnsamling
- Utbetaling av innskuddslønn
- Utstedelse av lån til en ansatt
- Andre utgifter
For utbetalinger #4-5 bør lønnsslipper utarbeides på forhånd, selv om utbetalingen skjer til én ansatt.
Figur 11. Varianter av kontantstyringsdokumentet
Vi vil utstede en kontantoppgjørstjeneste for utstedelse av midler til en ansvarlig person.
Figur 12. Utfylt kontantstyringsdokument
Etter å ha bokført dokumentet, kan du se transaksjonene.
Figur 13. Transaksjoner med kasseapparat
Vurder prosedyren for å utføre lønnsutbetalinger i 1C. La oss lage en lønnsliste. Hvis alle ansatte har fått lønn på det, kan du bruke knappen "Betal regningen" (nederst i skjemaet), det vil automatisk bli generert et kasseapparat.
Figur 14. Varianter av kontantdokumenter basert på lønn
La oss simulere en situasjon når lønn settes inn for en ansatt og betales for resten. I papirutgaven av oppgaven over de innsatte beløpene settes et tilsvarende merke. I 1C, når du regnskapsfører kontanttransaksjoner, åpne en kontoutskrift og bruk knappen Lag basert på, deretter Lønnsinnskudd. Til pantedokumentet legger vi igjen navnene vi trenger.
Figur 15. Lønnsdepositumsdokument
Etter å ha lagt ut dokumentet ser vi på postingene.
Figur 16. Transaksjoner ved innskudd av lønn
Vi går tilbake til listen og klikker på knappen Lag basert på vi danner et dokument Kontantuttak... Beløpet vil bli beregnet på nytt automatisk og vil være mindre med det innsatte beløpet.
Figur 17. Dokument Kontantuttak basert på lønn
Det ble generert lønnstransaksjoner for to ansatte, og det skal det være.
Figur 18. Transaksjoner på dokumentet Kontantuttak
De innsatte beløpene kan kun oppbevares i kassen dersom de ikke overstiger grensen for oppbevaring av midler. Ellers bør de overleveres til banken. Vi danner en kontantoppgjørstjeneste Kontantinnskudd til banken.
Figur 19. Fylle ut dokumentet Kontantinnskudd til banken
Resultatet av dokumentpostering.
Figur 20. Transaksjoner på dokumentet Kontantinnskudd til banken
Kassebok i 1C 8.3
Basert på PQS og RCOer som er utført i løpet av dagen, vil vi danne en kassebok (Figur 21), som er en rapport om de utførte kontanttransaksjonene.
En liten merknad: noen ganger under automatisering spør programmerere brukere hvordan de skal implementere et bestemt skjema - som et dokument eller som en rapport. Ofte er dette spørsmålet forvirrende. La meg forklare forskjellen ved å bruke eksemplet med kontantdokumenter. PKO eller RKO er egne dokumenter som det finnes påmeldingsskjema for. Beløpene til dem er som regel laget av brukeren selv, han kan endre dem om ønskelig. Kasseboken er en rapport, det er ikke noe påmeldingsskjema for den, den fylles ut automatisk basert på dataene som er lagt inn i dokumentene til kassa og kassa. Når du gjør endringer i disse dokumentene, vil rapporten, når den genereres, automatisk gi de allerede endrede beløpene.
Figur 21. Knapp for å danne en kassebok
For denne rapporten kan du konfigurere de nødvendige innstillingene.
Figur 22. Kassebokinnstillinger
Klar rapport.
Figur 23. Kassebokrapport
Forhåndsrapport
Et annet dokument som er en del av blokken Pengeboks i 1C-programmet - Forhåndsrapport
Figur 24. Menysti til dokumenter Forhåndsrapport
Tenk på et eksempel på å fylle ut en forhåndsrapport.
Figur 25. Opprette en utgiftsrapport
Tabelldelen inneholder flere faner. Vi fyller ut Forskudd-fanen basert på utstedt kontantoppgjørstjeneste.
Figur 26. Fullføre kategorien Fremskritt
Fanen Varer vi fyller inn data om de kjøpte varene eller materialene. Dersom mva er uthevet i dokumentene, angir vi disse dataene i forhåndsrapporten.
Figur 27. Fylle ut kategorien Produkter
Figur 28. Fanevarer, bankkontodetaljer.
I fanen innbetaling vi viser betaling for tidligere kjøpte varer.
Figur 29. Fylle ut fanen Betaling
Finn ut mer om bruk av faner Varer og Innbetaling.
Hvis du kjøper en enkelt vare fra en butikk, vennligst gjenspeil kjøpet i delen Varer. Men la oss si at du har en situasjon når du betaler med samme leverandør enten kontant eller via bankoverføring. Og du ønsker å ha korrekte data på beregningene, for eksempel for å danne en avstemmingshandling. Da kan fakturaer og fakturaer mottatt fra denne leverandøren på kjøpsdagen for kontanter bokføres separat fra forskuddsbetalingen med et dokument Kvittering (handlinger, fakturaer), og i forhåndsrapporten, gjenspeil detaljene i PKO, dvs. betalingsdokumentet på fanen Betaling.
Etter å ha bokført dokumentet kan du se transaksjonene. Mengden av forhåndsrapporten utgjorde 10 180 rubler, dvs. overforbruk på 180 rubler må utstedes fra kassen etter godkjenning av forhåndsrapporten.
Figur 30. Transaksjoner på forhåndsrapporten til BU og OU
Figur 31. JSC - fradragsberettiget mva
Betaling med betalingskort
Betaling med betalingskort, eller på annen måte anskaffe- er nå allestedsnærværende betalingsmåte for varer eller tjenester. La oss vurdere prosedyren for å utføre en slik operasjon i 1C.
Menybane: Bank og kasse => Kasse => Drift med betalingskort.
Figur 32. Menysti - Betalingskorttransaksjoner
Med knapp Skape tre versjoner av dokumentet er mulig. Vi velger Betaling fra kjøper, siden dette dokumentet er konfigurert for å gjenspeile betalinger fra juridiske personer og individuelle gründere. Detaljher utenfor rammen av denne artikkelen.
Figur 33. Velge en dokumentvariant
Vi fyller ut dokumentet, alt er ganske enkelt her.
Figur 34. Utfylt dokument Betalingskorttransaksjoner
Vi ser på ledningene. Midler reflekteres på konto 57.03.
Figur 35. Konteringer på bilaget Operasjoner på betalingskort
For å gjenspeile mottak av midler til brukskontoen, kan du opprette et dokument basert på operasjonen som er utført Kvittering til gjeldende konto.
Figur 36. Opprette et dokument Kvittering til en brukskonto
Det er usannsynlig at betalinger skjer uten bankens provisjon, så vi deler innbetalingen inn i betalingsbeløpet og bankens provisjon, og angir utgiftskontoen for denne provisjonen.
Figur 37. Utfylt dokument Kvittering til brukskonto
Vi ser på ledningene.
Figur 38. Konteringer på bilaget Kvittering til brukskonto
Drift med skatteregistratoren
Skatteskriveren er en teknisk enhet for utskrift av kvitteringer, har skatteminne, er koblet til en datamaskin og er i stand til å fungere over et nettverk. Menybane for tilkobling Administrasjon => Tilkoblet utstyr.
Figur 39. Meny for tilkoblet utstyr
I kapittel Skatteregistratorer enhetsdriveren må spesifiseres.
Figur 40. Velge driveren til skatteregistratoren
Hvis en ekte registrar ikke er tilgjengelig, kan du bruke en emulator fra 1C til testformål. Et eksempel på utfylling av data er vist nedenfor i figur 41.
Figur 41. Et eksempel på et fullført innstillingskort for skatteregistrator
Etter å ha koblet til skatteregistratoren, blir det mulig å skrive ut kvitteringer, for eksempel fra dokumenter PKO eller Betalingskorttransaksjon.
Figur 42. Skrive ut en kvittering i 1C-program
Dette avslutter vurderingen av temaet refleksjon av innkommende og utgående kontantordrer i 1C 8.3-programmet.
Hver plan har en viss liste over elementer, informasjon om endringen som den kan lagre. Denne listen kalles "Utvekslingsplansammensetning". Sammensetningen kan utvides, men konfigurasjonsstøtten fjernes.
Planoppsettet lagrer selve reglene som synkronisering fungerer på. Det er denne konverteringspakken (registreringsregler, utvekslingsregler, korrespondentutvekslingsregler) vi trenger for videre studier.
La oss vurdere et eksempel på datasynkronisering mellom konfigurasjonene "1C: Lønn og personalstyring 3" (ZUP) og "1C: Enterprise Accounting 3" (BP). Merk med en gang at i denne oppgaven må vi fjerne konfigurasjonen fra støtten. Dette vil være påkrevd av betingelsen.
Et levende eksempel på behovet for å ferdigstille standard bytteregler
For eksempel kontaktet en kunde oss med følgende problem: under synkronisering mellom ZUP og BP, er det ingen måte å overføre dataene til katalogen "Registrering hos skattemyndigheten", som er nødvendig for å fylle ut dokumentet "Refleksjon av lønn i regnskap». Nå inneholder den tabellformede delen av dette dokumentet på siden av BP-mottakeren en tom "Registrering ...", og brukere må manuelt opprette slike oppføringer i referanseboken. Enig, dette er upraktisk. Vi kan avgrense dette øyeblikket. 
Løsning på problemet: vi vil fullføre konverteringspakken fra utvekslingsplanen ExchangeSalary3Accounting3. La oss legge til standarden "1C Exchange Rules" en ny "Object Conversion Rule" (PKO) for referanseboken "Registrering hos Skattemyndigheten" og følgelig "Property Conversion" av denne referanseboken (PCS). Vi vil definitivt sluttføre standarden "Regler for registrering av objekter", siden det ble nødvendig å registrere endringer i katalogen på utvekslingsnoden. Og vi vil revidere "Regler for utveksling 1C" for korrespondentbasen.
Hvor skal vi redigere alt dette? for å skrive og endre reglene trenger vi 1C: Data Conversion 2-konfigurasjonen.
Endring av standard konverteringsreglene fra ZUP - BP Exchange Plan
Så vi vil begynne å fullføre 1C-utvekslingsreglene ved å legge til et nytt element i strukturen for utvekslingsplanen ExchangeZarplata3Accounting3 i konfiguratoren - registreringskatalogen i Skatteetaten. Vi vil gjøre denne endringen i begge konfigurasjonene "1C: Lønn og Enterprise Management 3" og "1C: Enterprise Accounting 3".
La oss lagre og oppdatere konfigurasjonene.
I bedriftsmodus, for hver database, vil vi laste ned beskrivelsen av metadatastrukturen ved å bruke MD83Exp.epf-behandling for 1C: Enterprise 8.3-plattformen. Behandling finner du i settet "1C: Datakonvertering".
På neste trinn vil vi laste ut konverteringspakken fra ZUP og BP. Pakken bør bestå av 3 filer: Registreringsregler, Utvekslingsregler, Korrespondentutvekslingsregler.
Innenfor rammen av denne artikkelen vil det ikke være noen beskrivelse av hvordan datasynkronisering er konfigurert, den kan leses på nettstedet til "Coderline"-selskapet i seksjonen Ekspertartikler eller se postene webinarer... Nå har databasene allerede konfigurert dette alternativet. Gå derfor til synkroniseringsinnstillingene (Administrasjon -> Datasynkronisering -> Konfigurer datasynkronisering), klikk på knappen "Last inn regler". Skjemaet «Regler for synkronisering» åpnes foran oss. Ved å klikke på "Mer"-knappen velger du elementet "Lagre regler til fil".
Etter lossing bør vi få en slik pakke.
Vi vil utføre lignende handlinger for en annen informasjonsbase "1C: Enterprise Accounting".
Som et resultat er alt det forberedende arbeidet for å redigere reglene klart. Vi har:
Beskrivelse av metadatastrukturen for lasting i 1C: Datakonvertering 2 (for ZUP og BP);
Konverteringspakke, som inneholder 1C-utvekslingsregler og registreringsregler som kreves for opplasting til 1C: Datakonvertering 2 (for ZUP og BP).
Gå til "1C: Datakonvertering 2". La oss utføre følgende trinn i rekkefølge for begge infobasene:
Vi laster inn metadatastrukturene til konfigurasjonene våre;
Vi lager konverteringer og laster inn 1C datautvekslingsregler fra konverteringspakker (regelfilen heter ExchangeRules);
Lag registreringer og last inn registreringsregler fra konverteringspakker (regelfilen heter RegistrationRules).
La oss gå direkte til revisjonen vår. I 1C-byttereglene legger vi til en ny regel for objektkonvertering (PKO) - katalogen "Registrering hos skatteetaten". Legg til en egenskapskonverteringsregel (PSC) for denne katalogen og en regel for dataavlasting (PST). Denne typen revisjon må utføres både for reglene fra ZUP-pakken og for utvekslingsreglene fra BP-pakken. Vi laster ut utvekslingsreglene våre i de tilsvarende ExchangeRules-filene.
La oss gå videre til reglene for registrering av et nytt element. Vi legger til katalogen "Registrering hos skatteetaten". Vi laster ut registreringsreglene i den tilsvarende filen fra RegistrationRules-pakken. Denne handlingen utføres også for begge basene.
De reviderte byttereglene og registreringsreglene er klare. Nå, inn i korrespondentreglene (CorrespondentExchangeRules) fra SPM-pakken, kopier innholdet av utvekslingsreglene (ExchangeRules) fra BP-pakken. I korrespondentreglene (CorrespondentExchangeRules) fra BP-pakken kopierer du innholdet av utvekslingsreglene (ExchangeRules) fra SPM-pakken.
Som et resultat bør du få følgende:
Dette fullfører arbeidet i "1C: Datakonvertering 2". De modifiserte pakkene med konverteringsregler er klare, det gjenstår å laste dem opp tilbake til infobasene og sjekke synkroniseringen.
Vi arkiverer filene fra pakkene til et ZIP-arkiv og laster konverteringspakkene våre inn i ZUP og BP.
Alt er klart. Det gjenstår å teste.
La oss huske betingelsene for problemet. Det var nødvendig å registrere seg for lossing av katalogen "Registrering hos skattemyndigheten" og sjekke hvordan PM til dokumentet "Refleksjon av lønn i regnskap" er fylt ut på siden av "1C: Enterprise Accounting 3".
I kilden "1C: Lønn og Enterprise Management 3" registrerer vi katalogen vår for lossing. Vi utfører synkronisering. Vi går til mottakerbasen og utfører også synkronisering for å motta data. Vær oppmerksom på at nå har bytteplanen den nødvendige katalogen for registrering av endringer.
Vi sjekker på siden "1C: Enterprise Accounting 3":
Oppsummer. Resultatet av oppgaven ble fullført. Vi har ferdigstilt ZUP - BP-utvekslingsplanen ved å legge til et nytt element for registrering av endringer og legge til konverteringsregler for datasynkronisering.
Send denne artikkelen til min e-post
Hovedårsakene til behovet for å implementere en utveksling mellom 1C-baser er tilstedeværelsen av filialer og separasjon av regnskapstyper, siden ofte opererer bedrifter i flere informasjonsbaser. Å sette opp utvekslingen av 1C 8.3 lar deg utelukke gjennomføring av dobbeltarbeid - legge inn de samme dokumentene og oppslagsbøkene i to programmer, samt raskt levere de nødvendige systemobjektene for forskjellige grener og avdelinger.
I tilfelle det er nødvendig å gjennomføre en utveksling mellom filialer, brukes RIB (Distributed Information Base). Det er en utvekslingsmekanisme mellom identiske konfigurasjoner. Det er et tre med den viktigste rotnoden på toppen, under et par beslektede noder. Endringer kan gjøres i hvilken som helst node i dette systemet, og de vil bli overført til andre relaterte noder. Fordelingen av ikke bare data, men også konfigurasjonsendringer fra rotnoden til de underordnede utføres på samme måte.
Hvis det er nødvendig å skille regnskapstypene, for eksempel å opprettholde en operativ en i en handelsdatabase, og en regulert i en regnskapsmessig, er universelle utvekslingsmekanismer med fleksible tilgjengelige.
En av de siste utviklingene i 1C er datautvekslingsformatet EnterpriseData. Den er enkel å bruke og er beregnet for utveksling innen et selskap både mellom 1C-databaser og tredjepartsprogrammer.
Implementeringen av datautveksling i bedriften kan representeres i form av sekvensielle prosedyrer.
Først av alt er det nødvendig å bestemme mellom hvilke baser utvekslingen skal være; vil det være en toveis eller enveis utveksling; hvis den er ensidig, hvilken base vil da overføre informasjon, og hvilken vil bare motta; hvis det er et komplekst filialnettverk, er det nødvendig å foreskrive en ordning for å bygge basene.
Deretter velger vi riktig format: RIB, universelt format; bytte i henhold til byttereglene; bytte uten bytteregler.
Neste trinn er å velge en transport for å utføre utvekslingen. Et stort utvalg av teknologier er tilgjengelig, vi vil fremheve de viktigste: en katalog (lokalt eller nettverk), en FTP-ressurs, COM-tilkoblinger, en webtjeneste, e-post.
Det fjerde trinnet vil være definisjonen av data: dokumenter, kataloger og, om nødvendig, detaljering til deres individuelle detaljer som skal overføres.
Og i konklusjonen er tidsplanen for utvekslingsfrekvensen foreskrevet
Hvert alternativ for å sette opp 1C 8.3-utveksling krever nøye forberedelse. Implementeringen er utenfor makten til hver bruker, her er det nødvendig å ta hensyn til mange nyanser og forstå prinsippene for utvekslingen. Spesiell oppmerksomhet må vies til å sette opp hvis databasene: inneholder modifikasjoner eller mange ekstra. detaljer, forskjellig i plattformversjoner eller utdaterte versjoner av konfigurasjoner brukes, bedriften er stor og bruker et automatisert system som består av et stort antall databaser. Feil er uakseptabelt her, fordi kan føre til uopprettelige konsekvenser. Uavhengig implementering av utveksling i 1C anbefales kun hvis du trenger å sette opp en enkel overføring av informasjon mellom typiske konfigurasjoner.
Hvis du tviler på evnene dine, er det bedre å ikke spare penger, men å kontakte en kompetent spesialist som vil bidra til å løse den vanskelige oppgaven med å sette opp 1C 8.3-utvekslinger.
Hvis du likevel bestemmer deg for å konfigurere 1C-sentraler uten å involvere eksperter, anbefales det at du først tester på kopier av databasene, og før du starter arbeidet i arbeidsdatabasene, laster du ut konfigurasjonene for å kunne gå tilbake til den opprinnelige tilstanden i tilfelle feil .
Nedenfor er et detaljert eksempel på å sette opp 1C 8.3-utveksling ensidig mellom standardkonfigurasjoner Trade Management 11 (UT) og Enterprise Accounting 3.0 (BP). Eksemplet er relevant for mange bedrifter som leder engros- og detaljhandel. I UT føres styringsregnskap, i BP - regulert er utvekslingen nødvendig for å lette arbeidet til brukerne.
Denne algoritmen er også egnet for andre typiske konfigurasjoner på 1C 8.3-plattformen.
Først og fremst skal vi utføre forberedende arbeid for informasjonsmottakeren, d.v.s. for PSU. Vi starter programmet i Enterprise-modus. Det er nødvendig å stille inn datasynkroniseringskonstanten (seksjon Administrasjon → Datasynkronisering).
Vær oppmerksom på Prefiks-feltet, her må du spesifisere en verdi som vil tillate deg å skille (ved verdien av referansekoden eller dokumentnummeret) i hvilket program objektene opprinnelig ble opprettet. I vårt eksempel er den vanlige forkortelsen egnet - BP og UT, hvis 1C 8.3-utvekslingsinnstillingen utføres for en kompleks utveksling mellom et stort antall baser, så vel som identiske konfigurasjoner, må du angi sin egen forståelige betegnelse for hver utgangspunkt.
Siden strømforsyningsenheten kun er en mottaker av informasjon, fortsetter vi med å sette opp UT.
Her, så vel som i BP, må du aktivere synkronisering og spesifisere prefikset. Denne informasjonen er tilgjengelig i avsnittet NSI og administrasjon → Innstillinger for datasynkronisering.
Velge en innstillingsmetode Angi innstillinger manuelt. Lengre.
Vi vil installere alternativet for direkte tilkobling, når begge programmene er plassert i samme lokale nettverk, vil vi indikere parametrene for å koble til IB-katalogen i dette nettverket, og også fylle ut autentiseringsinformasjonen om brukeren (i BP-databasen) . Lengre.
Systemet vil sjekke riktigheten av de spesifiserte dataene og, i tilfelle et positivt resultat, vil vise vinduet for 1C 8.3-utvekslingsinnstillinger.
Ved å klikke på koblingen Endre regler for opplasting av data får du tilgang til innstillingene for utveksling av utveksling. Vi vil avklare referansedataene - for å losse bare de som brukes i dokumenter, vil vi velge organisasjonen og muligheten til å jobbe med kontrakter - uten referanse, delingen av dokumenter i sammenheng med varehus. Begynnelsen av utvekslingen 1. mars inneværende år.
Vi skriver ned de innførte reglene og lukker dem.
Siden vi i eksemplet snakker om enveisoverføring av informasjon, må du angi Ikke send-verdiene i neste innstillingsvindu for å motta data fra et annet program. Brenn og lukk. Lengre.
Nå må du sjekke de angitte parameterne og hvis de er riktige, klikk Neste, ellers gå tilbake til forrige trinn ved å klikke Tilbake.
Deretter vil du bli bedt om å synkronisere. Klikk Fullfør.
Hvis det er nødvendig å korrelere identiske objekter av to konfigurasjoner, åpnes et vindu for sammenligning av data. Vi utfører sammenligningen og klikker på Neste.
Ved overføring av objekter kan det oppstå problematiske situasjoner; du kan se resultatene ved å klikke på koblingen Advarsler under datasynkronisering.
Etter at synkroniseringen er fullført, vises et vindu som bekrefter at denne prosessen er fullført.
Her, ved hjelp av kommandoen Konfigurer eller etter, i synkroniseringsskriptet, kan du konfigurere tidsplanen for automatisk utførelse av utvekslingen.
