Produksjonsbedriftsledelse. Produksjonsbedriftsledelse 1s opp 8.3 leksjoner

I denne artikkelen vil vi snakke om ERP-systemet "Manufacturing Enterprise Management". Ved automatisering av produksjonsbedrifter viser dette produktet seg ofte å være den optimale løsningen, og jeg har vært involvert i implementeringen av 1C UPP for forskjellige organisasjoner mer enn én gang.

Mens jeg jobbet la jeg merke til at det praktisk talt ikke er noen anmeldelser av dette programvareproduktet. Det er teknisk dokumentasjon, noen råd til programmerere om å løse spesifikke problemer i dette systemet, og opplæringskurs. Men for brukerne er det ingen klar beskrivelse av hele systemet. Og veldig ofte, før jeg implementerer dette programvareproduktet, må jeg forklare funksjonene, fordelene og ulempene ved "Manufacturing Enterprise Management" praktisk talt "på fingrene mine".

Selv på Habré i ERP-seksjonen var det fortsatt ingen informasjon om dette systemet. Det var dette gapet jeg bestemte meg for å fylle. I tillegg håper jeg at artikkelen min vil hjelpe gründere og IT-spesialister på stadiet med å velge programvare for å automatisere en produksjonsbedrift og forberede dem på funksjonene som må tas i betraktning når du implementerer dette systemet.

I denne anmeldelsen vil jeg fortelle deg hva UPP-utgaven er. 1.3, slik at den som bestemmer seg for å kjøpe og implementere det er mer bevisst og mer bevisst på å velge dette dyre produktet. Jeg vil prøve å gi en objektiv vurdering av systemet, basert på min erfaring med det og erfaringene til mine klienter. Denne anmeldelsen vil hjelpe noen til å ta en positiv beslutning angående kjøp av programmet, og noen vil bestemme seg for å forlate det.

For å forstå funksjonene til et programvareprodukt, må du svare på følgende spørsmål:

1. Hva er systemet, hvilke oppgaver er satt til det.
2. Hvor dyktig er dette systemet til å utføre sine tildelte oppgaver?
3. Identifiser fordeler og ulemper med systemet.

Det første som er veldig viktig å forstå: 1C. Produksjon av bedriftsledelse er ikke bare et regnskapssystem under utviklingen, moderne metoder for bedriftsledelse ble tatt i betraktning, og derfor tilbys dette produktet for bruk, inkludert som et ERP-system. Videre, av navnet følger det at dette spesielle produktet er beregnet på produksjonsbedrifter. Det er fra dette synspunktet jeg har tenkt å vurdere 1C UPP-programvareproduktet.

Hva er et ERP-system?

ERP-systemet (Enterprise Resource Planning) er et bedriftsinformasjonssystem som er utviklet for å kontrollere, registrere og analysere alle typer forretningsprosesser og løse forretningsproblemer i bedriftsskala.

Enkelt sagt kombinerer ERP-systemet alle typer regnskap som finnes i bedriften. Ved hjelp av ERP-systemer utveksles informasjon og samhandling gjennomføres mellom ulike avdelinger mv. Når det gjelder ERP-systemet "Manufacturing Enterprise Management", tilbyr programvaren implementeringen av alle disse funksjonene for en produksjonsbedrift.

Da de implementerte produktet "Manufacturing Enterprise Management", prøvde utviklerne å kombinere den maksimalt mulige listen over funksjoner i systemet. Ser du på dokumentene kan du telle hele 15 delsystemer. Faktum er at i 1C er dokumenter gruppert i undersystemer:

• Produksjonskontroll
• Kostnadsstyring
• Innkjøpsstyring
• Planlegger
• Skatt og regnskap
• Lønn
• Personalregnskap mv.

De. Vi prøvde å inkludere alle funksjonene som kan være nødvendige for driften av en produksjonsbedrift i dette systemet. Dette er nøyaktig hvordan 1C-selskapet posisjonerer ERP-systemet sitt: det har allerede alt du trenger for å automatisere eventuelle prosesser uten å bruke andre programvareprodukter.


Skjermbildet jeg tok viser tydelig at en svært liten del av dokumentene er direkte knyttet til produksjon. Alle andre dokumenter er tilleggsundersystemer designet for å gjøre "Manufacturing Enterprise Management" til en universell løsning for arbeidet til alle avdelinger. Jeg ser ikke noe poeng i å vurdere alle disse mulighetene i detalj, men det er viktig at hvert av delsystemene fungerer effektivt og fullt ut og kan løse behovene til en spesifikk virksomhet. I denne artikkelen vil vi dvele i detalj på blokken som skiller UPP fra andre 1c - Production Management-løsninger.

1C UPP: mer om produktet

1C-selskapet posisjonerer "Manufacturing Enterprise Management" som et av flaggskipsproduktene. Dette er en typisk konfigurasjon fra 1C, dvs. programvareproduktet er fullstendig produsert av 1C selv, og eventuelle modifikasjoner av systemet må utføres av offisielle 1C-partnere. UPP er en av konfigurasjonene som hele tiden støttes av 1C-oppdateringer, etc.

For denne standardkonfigurasjonen er det laget mange modifiserte, såkalte industriversjoner: 1C.Mechanical Engineering, 1C.Meat Processing Plant, 1C.Møbelproduksjon, 1C.Printing, etc.

Bransjeløsninger er laget av 1C-partnerselskaper basert på den grunnleggende konfigurasjonen. Dette skjer vanligvis som følger: modifikasjoner gjøres for en spesifikk kunde, hvoretter de "settes sammen" til en ny versjon beregnet for den valgte industrien. Den modifiserte konfigurasjonen er oppkalt etter bransjen den ble skrevet for og selges som en "boksløsning."

Produktkostnad

For å kunne jobbe med denne konfigurasjonen må du kjøpe selve produktet. Den anbefalte prisen fra 1C-selskapet er 186 000 rubler. Og lisensieringen av dette programvareproduktet utføres på felles grunnlag for 1C, dvs. brukere av andre 1C-produkter kan ikke kjøpe separate lisenser for dette systemet.

Enhver lisens, for eksempel fra 1C Accounting eller 1C Trade and Warehouse, passer for dette systemet. Naturligvis er kostnadene for lisenser for disse produktene de samme.

Det er viktig å forstå: For bransjeløsninger kan 1C-partnerselskaper kreve sine egne separate lisenser. Og her kan prisen avvike fra grunnversjonen.

Som når du arbeider med andre produkter, utføres lisensiering i henhold til et av alternativene som er akseptert i 1C: for en datamaskin (enhet) og for en bruker (tilkoblinger fra hvilken som helst enhet). Jeg vil ikke gå i detalj her, siden all informasjonen ligger på 1C-nettsiden. Du kan bli kjent med den på lenken: http://v8.1c.ru/enterprise/

Det er skrevet mye om selve 1C-programmet. Jeg har også allerede skrevet om denne plattformen, for eksempel i artikkelen "". Tar i betraktning det faktum at "Manufacturing Enterprise Management"-systemet opererer på grunnlag av 1C. Enterprise 8.3, alle fordelene og ulempene med den grunnleggende programvaren er også til stede i den.

La oss se nærmere på konfigurasjonen

I boken "Production and Operations Management" av R.B. Chase, F.R. Jacobs, N.J. Aquilano, likte jeg listen over oppgaver som legges til ERP-systemer for en produksjonsbedrift:

1. Hold oversikt over nye bestillinger og informer produksjonsavdelingen umiddelbart om dem.
2. Gi salgsavdelingen muligheten til å se statusen til kundens ordre når som helst.
3. Gi innkjøpsavdelingen mulighet til å se produksjonsbehov for materialer til enhver tid.
4. Å gi staten data om selskapets resultater i tide, dvs. føre regnskap og skatteoppføringer.

La oss se på hvert av disse punktene mer detaljert. For klarhetens skyld vil jeg bruke en av mine kunder som eksempel - en sybedrift som bruker SCP-systemet og er en klassisk og visuell produksjonsmodell. Denne bedriften har mange forskjellige avdelinger: design, engineering, produksjon, avdeling for lagring av stoff og tilbehør, avdeling for lagring av ferdige produkter, administrasjonsavdeling.

Regnskap for nye bestillinger i salgsavdelingen

Ordreregnskap er en integrert del av arbeidet til enhver salgsavdeling. Enhver ordre består av flere deler:

1. Kunderegnskap (som salget skjer til);
2. Regnskap for varer (hva skal selges til oppdragsgiver).

Kjøpere (klienter) føres inn i katalogen over motparter. Kunder kan være både enkeltpersoner og juridiske personer. I motpartskortet kan du angi alle selskapets bankdetaljer, telefonnumre, leveringsadresse og annen informasjon som er nødvendig for å behandle dokumenter og gjennomføre et salg.

Og detaljert informasjon om alle varer som kan selges er lagret i nomenklaturkatalogen.


En nomenklatur er en katalog som er laget for å lagre informasjon om varer og tjenester som kan leveres til kjøperen. Og i dette systemet er nomenklatur en av de mest komplekse oppslagsbøkene.

Følgende kan lagres her:

• Produktnavn
• Serie
• Bilder
• Teknisk dokumentasjonsfiler
• Beskrivelse og nesten all annen informasjon om produktet.

Ved hjelp av disse katalogene oppretter en salgsavdelingsmedarbeider et kundeordredokument, der han angir motparten og en liste over varer med priser.

Ved å bruke eksemplet på syproduksjon, er arbeidet med en ordre delt inn i følgende stadier:

1. Godta bestillinger og registrere kundebehov.
2. Om nødvendig, kjøp materiale for bestillingen.
3. Utfør skjæring og deretter sying av produkter.
4. Gjennomføre inspeksjon (kvalitetskontroll) av varer.
5. Overfør ferdige produkter til lageret.
6. Utføre forsendelse eller levering til kjøper.

Så den første fasen av arbeidet er fullført: kundeordredokumentet er opprettet, som gjenspeiler kundens data og varene han trenger. Nå må vi overføre informasjonen til produksjon.

Varsle produksjon om nye bestillinger

Produksjonen bør se nye bestillinger så snart de kommer. 1C UPP-konfigurasjonen takler generelt denne oppgaven. Men et motproblem oppstår: produksjonen skal kun se de ordrene som må produseres. De. Hvis ordredokumentet spesifiserer varer som allerede er på lager, er ikke produksjonen interessert i en slik ordre, og dens opptreden i listen over dokumenter tilgjengelig for produksjon kan skape ytterligere forvirring.

Produksjonen skal se bestillinger umiddelbart etter at de er mottatt, men kun den delen av bestillingene som produkter må produseres for.

For å unngå slike problemer tilbyr 1C-utviklere følgende løsning: basert på kjøperens bestilling må salgssjefen opprette et nytt dokument - Produksjonsordre, som vil liste produktvarene som må produseres.

Men dette alternativet kan ikke kalles veldig praktisk, siden det er ett trinn til i arbeidet, helt avhengig av den menneskelige faktoren. De. Etter å ha opprettet en ordre, kan lederen glemme å opprette en produksjonsordre, gjøre en feil og så videre. Som et resultat vil de nødvendige varene ikke bli levert til produksjonsplanen i tide, og kunden vil ikke motta de bestilte produktene i tide. Naturligvis, med full automatisering av virksomheten, er slike situasjoner uakseptable. På den annen side kan dette problemet løses fullstendig ved å opprette ytterligere behandling.

Vi har laget følgende løsning for et klesfirma. En ekstra plugin ble skrevet som oppretter en produksjonsordre automatisk basert på en bestemt liste over forskjellige forhold.

Denne behandlingen avgjorde om de nødvendige varene var på lager. Hvis ikke, så var neste trinn å analysere tilgjengelige varer i produksjon. Hvis det ikke finnes slike produkter eller de er planlagt til en dato senere enn spesifisert i bestillingen, genereres en produksjonsordre automatisk.

Konklusjon: Systemet har alt du trenger for å lagre informasjon om produkter og kunder. Det er mulig å opprette en ordre og overføre den til produksjon. Men for å fullautomatisere arbeidet, vil det fortsatt kreve modifikasjoner for å passe behovene til en spesifikk bedrift.

Status for en ordre i produksjon

Som allerede nevnt, etter at en ordre har kommet i produksjon, er det nødvendig å gi salgsavdelingen muligheten til å overvåke statusen til ordren i sanntid. Det er viktig for lederen av salgsavdelingen å vite på hvilket stadium arbeidet er: om de bestilte varene allerede er levert på jobb, når det planlegges ferdigstilt osv.

Dette implementeres på en av to måter:

1. Salgssjefen kan spore på hvilket teknologisk stadium arbeidet med ordren er: planlagt, inngått arbeid, ved kvalitetskontroll, etc. Dermed kan en salgsspesialist hele tiden overvåke arbeidet med hver ordre og varsle kunden om tidsfrister.
2. Det settes en salgsperiode for produktet, dvs. datoen når listen over nødvendige varer vil bli produsert, vil bli testet og vil være klar for sending.

Systemet gir ikke de nødvendige verktøyene for å implementere det første alternativet. Rapporter som er tilgjengelige gjenspeiler kun status for bestillinger og varer på lager. For produksjon, hvis det er nødvendig å implementere trinnvis varsling, vil det være behov for endringer.
Dessverre, i det andre tilfellet, er det ingen ferdige verktøy for tilfeller der produksjonen kan endre datoen for fullføring av ordren. Kun salgsavdelingen kan gjøre endringer på forsendelsesdatoen og oppover. Vanligvis kan lederen omplanlegge forsendelsen til et senere tidspunkt, men produksjonen vil måtte varsles om muligheten for å endre tidspunktet for opprettelsen av varer manuelt. Om nødvendig kan heller ikke produksjonen utsette forsendelsesdatoen, selv om det blir mulig å fullføre bestillingen raskere.

I grunnkonfigurasjonen utføres eventuelle endringer i tidsfrister og fastsettelse av stadiet for ordreoppfyllelse manuelt av ansatte, som et resultat av at den uforutsigbare menneskelige faktoren er inkludert i arbeidet. Men her vil forbedringer bidra til å løse problemet.

Så, for syproduksjon, laget vi en oppsummeringsrapport som viste: hvilket parti varer (fra hvilke bestillinger) er i produksjon, inkludert rapporten viser hvilket parti som er i skjæring, hvilket parti som er i sying, og så videre. De. vi delte inn produksjonsprosessene i stadier, og rapporten viste det overordnede bildet - hvilke produkter fra hvilke bestillinger er på hvilke stadier av produksjonen, hvilke som står i kø (angir startdato for arbeidet), hvilke er i kvalitetskontroll, som har vært sendt til lageret.

Opprinnelig ble denne rapporten laget for produksjonsarbeidere slik at de kunne overvåke arbeidet sitt og gjøre justeringer om nødvendig. Men senere åpnet vi den samme rapporten til salgsavdelingen slik at ledere også kunne se status for en bestemt ordre.

Konklusjon: Konfigurasjonen gir ikke mulighet for automatisk datautveksling mellom salgsavdelingen og produksjonen etter at bestillingen er sendt inn for behandling. Men det er mulig å implementere lignende løsninger basert på denne konfigurasjonen ved å lage flere rapporter og behandling.

Kommunikasjon mellom produksjon og innkjøpsavdeling

Et svært viktig poeng er å gi produksjonen de nødvendige materialene. Samtidig, for korrekt drift, er det nødvendig å gi produksjonen alt som er nødvendig for å oppfylle bestillinger og lage varer for gratis salg fra lageret, og på den annen side er det nødvendig at overflødig materiale ikke samler seg på lageret. Derfor må forsyningsavdelingen ha tilgang til oppdatert informasjon om mengde materialer på lageret og aktuelle produksjonsbehov, inkludert en liste over materialer for bestillinger som nettopp er planlagt for produksjon.

Hvordan dette arbeidet skal skje:

1. En liste over behov genereres.
2. Basert på denne listen og produktspesifikasjonene, dannes en liste over materialer som er nødvendige for produksjon av produkter.
3. Basert på den mottatte listen dannes det en anskaffelsesplan.
4. I henhold til innkjøpsplanen genererer systemet bestillinger til leverandører.

En viktig ulempe med systemet: Innkjøpsavdelingen har ingen mulighet til å se hvilke materialer som må kjøpes fra hvilke leverandører og til hvilke priser. De. rapportene viser kun generelle aktuelle produksjonsbehov, og for å få mer detaljert informasjon må det gjøres ytterligere modifikasjoner.
Systemet har et dokument kalt Innkjøpsplan. Den samler inn informasjon om behov, d.v.s. om hva som må kjøpes inn for å sikre produksjon og i hvilken mengde, slik det skal være i et klassisk MRP-system.


MRP (Material Requirements Planning)– dette er automatisert planlegging av virksomhetens behov for råvarer og materialer til produksjon. Planlegging gjøres basert på spesifikasjoner.

Spesifikasjon (materialeliste) er en oppslagsbok som beskriver alle parametrene til et bestemt materiale, dets kvaliteter, egenskaper, toleranser. For et ferdig produkt eller "halvfabrikat" angir spesifikasjonen hva produktet består av.

Produksjonen av hvert produkt krever visse materialer og halvfabrikata. Materialer kan bestilles umiddelbart basert på spesifikasjoner. For halvfabrikata er det nødvendig å ta neste skritt - for å finne ut hvilke materialer, i sin tur, dette eller det halvfabrikatet består av. Og legg også til de nødvendige materialene til bestillingen.

Dermed blir hvert ferdig produkt automatisk delt inn i materialer ved hjelp av flere trinn. For eksempel:

Dressen består av bukse, jakke og emballasje (pakke). Bukser og en jakke er halvfabrikata som må dekomponeres i neste trinn for å lage en pakke, materialet kan umiddelbart legges til kjøp. I det andre trinnet er buksene «delt inn» i ulike typer stoff, tråd, glidelås og knapper. Tilsvarende består en jakke også av ulike typer stoff, tråder og knapper. Alle disse materialene legges til kjøpsplanen.

Nå kan du velge en leverandør for hvert av materialene og opprette en ordre. Alle de ovennevnte stadiene i SCP-systemet er ikke automatiserte, og derfor vil det være nødvendig med noen modifikasjoner for å løse problemet. Samtidig gir konfigurasjonen muligheten til å lagre alle krav, og det er også mulighet for å samle inn anskaffelsesinformasjon. Men i den grunnleggende versjonen krever de alle menneskelig inngripen, noe som reduserer nivået av bekvemmelighet og pålitelighet. Derfor vil ekstern behandling også være svært nyttig her, spesielt siden all data og tilgang til den er tilgjengelig i systemet.

For syproduksjon løste vi problemet som følger. Basert på rapporten utviklet for produksjon, samt informasjon om bestillinger, ble behovet for nødvendige materialer automatisk beregnet. Deretter ble materialer lagret på lageret trukket fra denne listen, og det ble opprettet en rapport ved hjelp av hvilke kjøp kunne gjøres. Leverandører forteller deg deretter hvor raskt de kan levere materialene. Og denne informasjonen legges manuelt inn i systemet, på grunnlag av hvilke selgere vil kunne varsle kundene om tidspunktet for ordreproduksjon.

Regnskap og skatterapportering i en "boksløsning"

Den typiske konfigurasjonen av "Manufacturing Enterprise Management", slik utviklet av utviklerne, bør samle all informasjon som er nødvendig for regnskaps- og skatterapportering og opprette all rapportering som er nødvendig for arbeidet til regnskapsavdelingen.
Og her har denne konfigurasjonen en veldig stor "akilleshæl". Faktum er at i hvert dokument er det tre avmerkingsbokser:

• УУ – dokument om ledelsesregnskap;
• BU - dokumentet er underlagt regnskap;
• NU – dokumentet er skattepliktig.

Siden dokumenter ikke er delt inn i ulike systemer, spiller den menneskelige faktoren inn. For eksempel poster en ansatt i innkjøpsavdelingen eller en lagerholder, etter å ha mottatt materialer, et kvitteringsdokument. Materialet er registrert. Men hvis han ikke krysser av i BU-boksen, så ser ikke regnskapsføreren dokumentet, og han posterer selv fakturaen basert på skattefakturaen han har mottatt. Som et resultat blir dokumentet rettet to ganger av forskjellige forfattere. Og hvis det oppstår feil, vil det være svært vanskelig å identifisere den skyldige.

Jeg vet ikke hvordan dette problemet er løst i forskjellige tilfeller. Så langt har jeg kommet over alternativer der ledelsen var enig i denne mangelen og foretrakk å stole på ansatte. Den eneste metoden for beskyttelse mot menneskelige feil som er implementert er å sette standard avmerkingsbokser. I prinsippet, i de små og mellomstore bedriftene som jeg vanligvis jobber med, er dette egentlig nok.

Integrasjon med andre programvareprodukter og systemer

Integrasjon er et viktig stadium som er nødvendig når du automatiserer arbeidet til enhver bedrift, inkludert produksjon. Det er nødvendig å forstå at integrering er en kostbar prosess som tar en betydelig mengde tid og krefter. Siden vi snakker om et komplekst multifunksjonelt ERP-system, for høykvalitets automatisering av prosesser vil det være nødvendig å skaffe en stor mengde forskjellige data fra forskjellige kilder.

Hvis du ser på det fra et produksjonssynspunkt, må du definitivt laste inn data om produktutgivelsesdatoer, halvfabrikata og materialer inn i systemet. Innkjøpsavdelingen laster opp følgesedler og andre kvitteringsdokumenter i systemet. Salgsavdelingen skal laste opp informasjon om bestillinger og så videre. I tillegg er ulike situasjoner mulig i produksjonen, og det er svært viktig at systemet raskt mottar informasjon om materialforbruk, feilrater, omlegging av produksjon på grunn av noen vanskeligheter som oppsto under arbeidsprosessen, etc.

For eksempel, på en sybedrift, ble integrasjon utført med en skjæremaskin. Integrasjon med enhver CAD, med selskapets nettside eller med andre løsninger er også ofte nødvendig. Og dette stadiet av arbeidet tar ofte opptil 30% av budsjettet.
Samtidig, uten slike omfattende løsninger, vil bruken av et EPJ-system ikke være effektiv, du vil ikke kunne nå et nytt nivå av kontroll og automatisering av virksomheten. Dette er veldig viktig å forstå.

Ethvert system er bare så effektivt som dets svakeste ledd. Og hvis du under implementeringen nekter å integrere i ett eller annet tilfelle, og stoler på den menneskelige faktoren, vil feil sikkert samle seg, og hele systemet vil bli ustabilt.
Hvis vi for eksempel snakker om å designe et nytt produkt, så skal all designdokumentasjon lastes opp fra designsystemet (CAD) til ERP-systemet automatisk. Og så, hvis det oppstår spørsmål eller vanskeligheter, vil det alltid være mulig å forstå hvilket spesifikt produkt vi snakker om. Og designere vil kunne gjøre de nødvendige endringene raskt og uten feil.

Når det gjelder produksjon er det svært viktig å få rettidig og feilfri informasjon om innkommende bestillinger (for eksempel fra en nettside eller fra et spesialbestillingsskjema) som må produseres, samt rettidig og feilfri overføring av informasjon om de faktiske materialene som brukes, noe som vil tillate at arbeidet fortsetter uten nedetid.

Jeg nevnte allerede ovenfor at på sybedriften var det nødvendig å integrere med en skjæremaskin som kuttet 36 lag med stoff samtidig, det var nødvendig å skaffe informasjon om rester, mengden av skrap og fordele dette skrotet blant kostnadene for; hele produktpartiet. Følgelig var det nødvendig med et tillegg som var direkte integrert med maskinen slik at systemet forsto dataene som kom ut av den og sendte data til maskinen i et format som det kunne forstå. I tillegg var det nødvendig å behandle dataene som ble mottatt fra maskinen for å beregne feil og produktkostnader.

Også i mange andre tilfeller er det uakseptabelt å stole på den menneskelige faktoren, siden feil, unøyaktigheter i systemet og utidig inntasting av informasjon fører til forstyrrelser i arbeidet. Derfor er integrering selvfølgelig ikke en rask og kostbar prosess, men det er nødvendig for å forbedre kvaliteten på arbeidet.

Bransjeløsninger

I tillegg til den grunnleggende konfigurasjonen av 1C. Det finnes et betydelig antall bransjeløsninger for SCP. De er laget av 1C-partnerselskaper basert på den grunnleggende konfigurasjonen. Oftest vises slike løsninger som et resultat av implementeringen av 1C.UPP for noen produksjonsbedrift. Etter det blir den modifiserte versjonen av konfigurasjonen for en bestemt bransje litt modifisert og tilbys som en ferdig bransjeløsning til kunder.

Nå på 1C-nettstedet kan du finne slike konfigurasjoner for nesten alle bransjer. Men det er veldig viktig å forstå følgende punkter:

1. Konfigurasjonen ble endret for å passe behovene til en spesifikk bedrift. Og det er ingen garanti for at denne tilnærmingen vil være riktig for din bedrift. For eksempel kan meieriproduksjon lage cottage cheese og rømme etter vekt, eller den kan pakke disse produktene i visse beholdere. Den kan produsere melk, kefir og fermentert bakt melk, eller den kan spesialisere seg på yoghurt og desserter. Hvert av disse tilfellene vil kreve forskjellige modifikasjoner. Og det er ikke et faktum at de som tilbys i basisversjonen fra partnere vil passe deg.
2. Bransjekonfigurasjoner utføres av partnerbedrifter på grunnlag av den viktigste, mens det gjøres betydelige endringer i selve konfigurasjonen. Derfor oppdateringer for den grunnleggende versjonen av 1C. Mykstartere er ikke egnet for en industrikonfigurasjon. Brukere må vente til 1C-partnerselskapet også oppdaterer bransjeversjonen.

Noen få ord om 1C. UPP ERP 2.0

Det er også en egen 1C-konfigurasjon. UPP ERP 2.0, som betydelige forbedringer og tillegg ble nødvendig for å automatisere administrasjonen av en produksjonsbedrift. De. denne konfigurasjonen er ikke bare posisjonert som en komplett løsning, men som en universell løsning for en produksjonsbedrift som inkluderer et fullverdig ERP-system.

Dette systemet er også laget på grunnlag av 1C, konfigurasjonen er også omfattende, ikke modulær. Derfor er alle funksjonene til 1C-produkter, i prinsippet, så vel som problemene som oppstår ved implementering av komplekse 1C-konfigurasjoner, også iboende i dette systemet.

På den ene siden versjon 1C. UPP ERP 2.0 har virkelig et utvidet sett med funksjoner, primært relatert til automatisering og administrasjonsproblemer. Men dette programvareproduktet ble laget relativt nylig. Og jeg mener at det er for tidlig å bytte til denne versjonen på grunn av at den ennå ikke er ferdig utviklet.

Den oppdateres kontinuerlig med nye funksjoner, nye oppslagsverk, dokumenter, rapporter, i motsetning til 1C. UPP, som oppdateringer kun inkluderer rettelser av identifiserte feil og oppdateringer av regnskap og skatterapportering knyttet til endringer i lovgivningen.

I tillegg kommer 1C-systemet. UPP ERP 2.0 er mye dyrere enn 1C-konfigurasjonen. UPP.

Fordeler og ulemper med 1C UPP-systemet

Systemet er virkelig omfattende, og med passende modifikasjoner kan det utføre funksjonene til å administrere en produksjonsbedrift av en bestemt type. Det er også viktig å forstå at hver bransje vil kreve forskjellige forbedringer. Hvis systemet ble opprettet for å sy klær, vil det ikke være egnet for en meieriproduksjonsbedrift. Du kan selvfølgelig også bruke bransjeløsninger, men jeg personlig anbefaler ikke å bruke slike løsninger.

Ganske enkelt fordi hvis standardkonfigurasjonen av "Manufacturing Enterprise Management" ikke passer deg på mange måter, vil bransjeløsninger heller ikke passe deg. I dette tilfellet vil det være lettere å velge et annet produkt eller faktisk bestille en tilpasset løsning. Og hvis standardkonfigurasjonen passer deg for det meste, vil antallet modifikasjoner og innstillinger som passer til egenskapene til en bestemt virksomhet for en standardløsning og en bransjespesifikk løsning være lite forskjellig.

En viktig ulempe med systemet er mangelen på modularitet. De. For å løse visse problemer, kan du opprette bestemte behandlinger eller rapporter, "tillegg" til systemet. De vil fungere, men de grunnleggende løsningene vil forbli urørt. Men hvis du for et eller annet formål trenger å gjøre endringer i arbeidet med dokumenter eller referansebøker, må du gjøre endringer i alle undersystemer som finnes i konfigurasjonen.

På grunn av mangelen på modularitet i dette systemet, er det umulig å gjøre noen vesentlige justeringer av regnskapet eller for eksempel arbeidet med lagerregnskap uten vesentlige endringer i dokumenter og kataloger beregnet på andre avdelinger. De henger alle sammen og arbeider med de samme oppslagsverkene og dokumentene. Imidlertid er denne funksjonen viden kjent, siden den er iboende i alle programvareprodukter fra 1C.

Derfor er det vanligvis ingen som gjør vesentlige forbedringer i dette systemet, de prøver å nøye seg med ekstern behandling, rapporter og andre tillegg. Bransjeløsninger er som oftest bare en variant av et sett med tillegg som ble laget for en spesifikk bedrift relatert til et spesifisert område. Og du vil fortsatt trenge noen modifikasjoner, kostnadene for disse varierer lite fra modifikasjoner til den grunnleggende konfigurasjonen. Men påliteligheten til en standardløsning er alltid høyere enn produkter fra partnerbedrifter.

Konklusjon. Hvis du er fornøyd med den grunnleggende systemkonfigurasjonen, er det best å kjøpe og installere den. Men samtidig er det veldig viktig at implementeringen av systemet utføres av erfarne spesialister som ikke bare kan konfigurere programvaren, men også gjøre alle nødvendige forbedringer for virksomheten din, rapporter og utføre integrasjon med andre programvareprodukter og systemer.

Med riktig tilnærming blir 1C Manufacturing Enterprise Management-systemet et utmerket verktøy som lar deg oppnå et høyt nivå av automatisering av forretningsprosesser og koordinering av arbeidet til forskjellige avdelinger i selskapet.

Som en konklusjon vil jeg gi noen råd til de som har bestemt seg for å kjøpe og implementere programmet “1C: Manufacturing Enterprise Management 8 edition 1.3”:

1. Velg en strategi

SCP er et komplekst og stort produkt som hevder å være universelt. Produktet er dyrt, og jeg snakker her ikke bare om kostnadene ved anskaffelse, men også om kostnadene ved å eie programmet - kvalifiserte spesialister er dyre, og det er svært få av dem. Velg en strategi og finn ut hvorfor du kjøper dette spesielle programmet og hvordan du vil bruke det, hva du skal gjøre med det videre.

Hva er de forskjellige strategiene? En av mine klienter valgte denne konfigurasjonen fordi "det er det eneste systemet som har alt." Denne bedriften jobbet i flere systemer: 1c, Excel, etc. - de bestemte seg for å ta ett system for å konsolidere regnskapet.

Et annet selskap, som utviklet produksjonen, ønsket å kontrollere pågående arbeid – de var bekymret for regnskapsføring av materialer i produksjonen. Dette er også en strategi.

2. Vurder integrasjon

Integrering må tenkes gjennom i første omgang for å vurdere hvilke økonomiske og tidsmessige ressurser som skal brukes på implementeringen. En objektiv vurdering av dette faktum kan påvirke beslutningen om å kjøpe dette programmet eller gi preferanse til et annet produkt.

3. Vurder behovet for SCP i forhold til bedriftens størrelse

SCP passer ikke for alle bedrifter. Jeg så et selskap som sysselsatte 15 personer. De "arvet" på en eller annen måte SCP-systemet, men implementering og modifikasjon kostet mye penger, og til slutt byttet de aldri til SCP. Du må forstå at hvis din bedrift ikke er tilstrekkelig forberedt til å jobbe med et så komplekst produkt, så vil det ikke ha noen effekt. Jeg anbefaler ikke denne konfigurasjonen for et lite selskap.

4. Vurder behovet for SCP fra et industriperspektiv

Selv om 1c skriver at UPP er en universalløsning, må man forstå at den kun egner seg for monteringsproduksjon, som innebærer å sette sammen ett helt produkt fra flere deler. For produksjon av for eksempel byggematerialer og blandinger var denne konfigurasjonen ikke egnet.

I denne videosamlingen vil jeg prøve å lage en virkelig enkel og forståelig opplæring for nybegynnere i å mestre programmet. Hver videoleksjon vil dekke et spesifikt emne: fra første introduksjon til programmet til innlevering av skatterapporter.

Forresten! Spesialistene våre har jobbet hardt for å skrive et stort antall trinnvise instruksjoner for 1C Accounting-programmet.

Jeg vil kanskje starte med personlig erfaring og gi et par tips om hvordan du raskt kan lære programmet og ikke gå seg vill i det.

Det er alltid skummelt å begynne å jobbe med en gang med ekte bedriftsdata i en ekte database. Og denne frykten har et grunnlag - å trykke på et par ekstra knapper kan føre til ødeleggelse av mange års data, kansellering av fridager for den neste måneden eller to. Ja, og nerver er ikke unødvendige.

En vanlig tom 1C Accounting-database vil hjelpe deg å overvinne frykt og bli mer selvsikker (om hvordan du oppretter den). Før du jobber i "levende 1C-databasen", trenger en nybegynner ganske enkelt å gå gjennom alle operasjonene fra A til Å: sette opp programmet, opprette en ny organisasjon, opprette motparter, kontoer, salg, beregne kostnadene, lukke måneden, utarbeide rapporter osv.

Du vil møte mange problemer, i løpet av disse vil du begynne å løse forstå programmet. Det viktigste er at du forstår hele forholdet mellom å klikke på "en slags hake" og resultatet i rapporteringen. Men når du klikker på "dette merket" i begynnelsen av kvartalet, vil du selvfølgelig ikke huske det på slutten av kvartalet. ( Selvfølgelig er en beskrivelse av alle programparametrene i litteraturen, men hva slags landsmann leser instruksjonene? 🙂)

Hvis du allerede har fullført et slikt "ung jagerkurs", så ikke slett treningsbasen din, men hold den alltid for hånden. Du kan alltid bygge et testeksempel og sjekke hvordan programmet oppfører seg i et bestemt tilfelle.

Det kan være veldig nyttig å lage en kopi av arbeidsdatabasen og trene på den. Tro meg, mange regnskapsførere med til og med 20 års erfaring i å håndtere 1C utfører eksperimenter på testbaser før viktige prosedyrer.

Videoer og artikler om 1C

Nødvendigvis abonner på vår kanal på Youtube , vi slipper jevnlig nye videoer!

Video opplæringsspilleliste på YouTube, der de mest populære operasjonene i 1C Accounting analyseres sekvensielt:

Hvis du ikke kan se videoer, les artiklene våre på nettet.

Hvorfor ble denne artikkelen født?

1. Vi hadde allerede en, som vakte stor interesse (14306 visninger). Dette emnet er 2 år gammelt og mye har allerede endret seg. Folk fortsetter å kontakte oss og ber om en oppdatert versjon.

2. 1C ga ut en ny konfigurasjon "ERP produksjonsstyring 2.0", vi deltok til og med på et seminar, men igjen så vi ikke en god løsning på planleggingsproblemet.

Derfor bestemte vi oss for å generalisere vår erfaring og beskrive ikke bare planlegging, men hele spekteret av løsninger.

Nedenfor har vi skissert et diagram over hva vi planlegger å snakke om i detalj. Alle disse punktene er viktige, etter vår mening. Vi vil fokusere på viktige punkter som enten er nødvendige eller som i stor grad forenkler livet.

Emnet er stort, mange behandlinger og rapporter krever modifikasjon for en standardkonfigurasjon - vi vil prøve å ikke forsinke det.

1. Kjøpers bestillinger.

All produksjon er designet for å oppfylle kundeordrer. Det er vanskelig å oppdage Amerika her. Men i dag må vi ta hensyn til flere funksjoner for å unngå overraskelser.

1. Tilstedeværelsen av komplekse ordninger for videresalg av ferdige produkter, når en holdingorganisasjon produserer produkter, selger den andre, den andre..... etc. og bare den n'te selger til en tredjepart. Fører til et stort antall bestillinger, hvorav kun en liten del går i produksjon.

2. Tilgjengelighet av flere varehus for ferdige produkter. For eksempel: klær og sko, metall og elektroder, etc. Men kjøperen gjør bestillingen alene, og jeg vil egentlig ikke dele den opp.

3. Varehus og deres mengde er i konstant endring. Dette er ofte forbundet med utskifting og fremveksten av nye organisasjoner.

4. Tilgjengelighet av eksterne lagre og, som et resultat, varehus på veien. Alle disse produktene må reserveres og på ingen måte settes tilbake i produksjon.

Vi kom til en enkel løsning på alle disse problemene med nesten standard funksjonalitet. Det er tatt i bruk en løsning som, mest overraskende, fungerer uten ekstra kontroll. Så,

1. I kundeordrer er kun lagertilgjengelighetsgrupper angitt i lagerfeltet. Dette løser umiddelbart problemet med flere ferdigvarelager og fremveksten (stenging av gamle) nye varehus. Lederen fortsetter å jobbe med sin tilgjengelighetsgruppe.

2. Katalogen over grupper for lagertilgjengelighet har et hierarki aktivert - den lar deg gruppere grupper og varehus med samme funksjonalitet

3. "Produksjon"-attributtet med den boolske typen er lagt tilalogen.

Punkt 2,3 løser oppgave 1,3,4 sammen.

Hvorfor blir ikke lederen forvirret og feilaktig (han er naturligvis lært opp) i lagerfeltet selve lageret, og ikke tilgjengelighetsgruppen, fordi funksjonaliteten til å overføre en ordre til en produksjonsordre er automatisert (ordrer der et lager , og ikke en gruppe, behandles ikke - dette er en "samtale"), og produksjonsordrer som inkluderer et lager faller ganske enkelt ikke inn i planleggingen, og lederen, hvis han jobber, vil selvfølgelig umiddelbart se problemet med hans rekkefølge. Riktignok er det få slike feil med god trening (oppmerksomheten skjerpes).

Sikkerhetslager av ferdige produkter og interoperasjonelle lagre av PF.

I tillegg til kundeordre, må produksjonen opprettholde en slags sikkerhetslager av ferdige produkter i SOE-lagre, og det er ofte nødvendig å redusere produksjonstiden, interoperasjonelle lagre av halvfabrikata. Svært ofte utføres alle disse funksjonene av interne bestillinger eller til og med kjøperordrer, men etter vår mening krever bestillinger konstant overvåking, de må åpnes, lukkes, fjernes fra reserver, etc. Bestillinger har en ulempe til - til og med ett produkt vil bli laget i henhold til det hvis det ikke er nok av det. Ledelsen ønsker virkelig at sikkerhetslagrene skal fylles på ikke én om gangen, men i grupper. Dette sikrer omsetning av forsikringslagre (forsikringslager lagres ikke på lageret) og enhetlig produksjonsbelastning. Hvordan vi implementerte dette selv:

Det ble besluttet å bruke dokumentet "Innstilling av ordrepoengverdier". Hvorfor?

1. Til nå har vi ikke brukt dokumentet.

2. I kjernen er den veldig nær det vi ønsket fra den.

3. Vi var nesten helt fornøyd med tilstedeværelsen av TC-detaljer. Bare ett attributt, Prioritet, ble lagt til PM.

Hvordan brukes dokumentdetaljer?

1. Nomenklatur og kjennetegn - alt er klart.

2. Bestemmelsesmetode - Fast. Bestemmer type andre detaljer og manuell regnskapsføring.

3. Ordrepoengverdi - ikke brukt.

4. Sikkerhetsbeholdning - den faktiske verdien av sikkerhetsbeholdningen.

5. % poengverdi - minimumsverdien av sikkerhetslageret i prosent, i nærvær av hvilken en ny batch lanseres for produksjon.

6. % av sikkerhetslageret - den prosentvise verdien av sikkerhetslageret der lanseringen av en ny batch stopper.

7. Lager - ikke brukt.

8. Prioritet - lar deg trekke opp saldoer riktig i planleggingen. La meg forklare. Anta at du har spesifisert 100 ferdige varer H1 som sikkerhetslager og 100 varer H2 som interoperabel inventar. Produkt H1 består på et tidspunkt av produkt H2. På planleggingstidspunktet har du 50 stk H2-produkter i produksjon. Hvis du ikke angir en prioritet, kan saldoene trekkes opp til den interoperasjonelle beholdningen, og sikkerhetsbeholdningen vil starte fra bunnen av. Det er tydelig at vi ønsket akkurat det motsatte resultatet. Det er her Prioritet kommer inn i bildet. Han sorterer halvfabrikata mellom forsikring og interoperable varelager.

Det viktigste spørsmålet er: hvordan kommer alt dette inn i planleggingen?

Svaret gjør deg kanskje ikke særlig glad, fordi... Vi har vår egen planlegging og den vil bli diskutert nedenfor. Etter at synkroniseringen (også i planleggingsemnet) av kundeordrer finner sted, bestemmer planleggeren hvor mange forsikrings- og interoperasjonelle bestillinger vi har på lager (det spiller ingen rolle om de er på lageret eller i produksjon) og hvor mange som skal bli lansert, under hensyntagen til minimums- og maksimumsprosenten for produksjon.

Vel, og nok en gang et eksempel på hvordan det fungerer: Forsikring 200 stk, minimum 10% (20 stk), maks 90% (180 stk).

1. Det er for tiden 10 stk. Flyskroget går over til etterfylling og setter 190 enheter i produksjon.

2. Det er 100 enheter og den forrige planleggingen var for påfylling, så vil ytterligere 100 enheter lanseres.

3. Det er 185 stk. Seilflyet vil slutte å lansere og vente til antallet faller under 20 stykker.

4. Det er 100 stykker og forrige planlegging var en nedgang, da vil vente til mengden faller under 20 stk.

Hvis minimums- og maksimumsprosenten ikke er angitt, kjøres alltid kvantumet som mangler.

Reservasjon.

Hvorfor er reservasjon nødvendig?

For seilflyet spiller det ingen rolle om produktene er reservert for bestilling eller ikke. Den synkroniserer alle ordresaldoer i henhold til rangeringen (for oss er dette bare datoen for ordren; alle de vanlige administrasjonsproblemene, for eksempel en viktig ordre, etc., forstyrrer bare arbeidet, og hvis det virkelig er nødvendig, er det løst innen samme dato). Det spiller ingen rolle hvor produktene er for øyeblikket - på fastlegelageret, i produksjon ved mottak, reparasjon osv. Det viktigste er overholdelse av det nødvendige settet med kvaliteter og kostnadselementer. De ødela det – de endret kvalitets- eller kostnadsposten, og Planer ser ikke lenger disse varene.

Betydningen av redundans øker og er viktig i følgende tilfeller:

1. Du kan alltid se status for ordren på lageret.

2. Du kan reservere varer for bestilling med en senere dato manuelt.

3. Tilgjengelighet av eksterne lagre og varehus på veien. Vær oppmerksom på: dette er ikke filiallagre, da er det rett og slett 2 forskjellige bestillinger, nemlig produksjonslagre, men langt unna produksjon. Du kan jobbe med slike varehus bare gjennom reserver. Det finnes produkter for en spesifikk bestilling for kunder som sendes fra disse varehusene. Det er mulig å holde ledige rester der, men å planlegge dem er problematisk, siden du i dette tilfellet også må ta hensyn til den territorielle avsidesheten.

Og siden reservasjon er viktig, er det behov for å gjøre det automatisk. Det vil si at vi trenger slik behandling som kan settes i gang både manuelt og ved rutineoppgaver, og reservere alt som ankom lagrene eller lå der i fribalansen for kundebestillinger. Samtidig vet alle som har jobbet med reserver at jambs stadig kommer ut med dem, som er av følgende typer:

1. Negative reserver, dvs. salg var fra reserven, men det var ingen reserve.

2. Overskuddsreserver på bestillinger, det er 5 stykker i bestillingen, og 6 stykker er reservert for det.

3. Frie saldoer ble negative på grunn av reserver som oversteg saldoene.

4. Reserver som det ikke er gjenværende varer for på lageret.

Vi kommer til den konklusjon at vi først og fremst må eliminere alle problemer og først deretter gjøre en reservasjon. I tillegg bør det være valg slik at selektive reservasjoner kan gjøres. Vi tilbyr deg slik behandling til en minimal pris. Utvalget er organisert etter et sett med lagertilgjengelighetsgrupper og en kombinasjon av en liste over varehus og en liste over tilgjengelighetsgrupper. I tillegg kan behandlingen ganske enkelt fungere i feilelimineringsmodus. Det er ikke noe vanskelig å behandle, hvem som helst kan skrive en selv, og hvis du er for lat til å starte fra bunnen av, ta vår. Behandlingen har en funksjonalitet for å lagre innstillinger. For de som er interessert,.

(Overføring av bestillingen til produksjon. Hvordan organisere rabatter mellom organisasjonene dine.

Planlegger.

Planleggingsrapporter.

Utstedelse av oppgave eller CVD.

Hvor kan jeg få tak i settet eller LZK.

Vis implementering av CVD.

Plan fakta.

Produksjonstider for produkter og backlogkontroll.

Analyse av effektiviteten til sikkerhetslagrene.

Kontroll av frosne produkter.

Kjennetegn på nomenklaturen eller hvordan man kan omfavne det enorme.)

I denne delen starter vi en gjennomgangsserie med artikler som vil hjelpe deg å mestre "1C: Manufacturing Enterprise Management"-konfigurasjonen.

Introduksjon

"1C:Manufacturing Enterprise Management 8" er en omfattende applikasjonsløsning som dekker hovedkonturene av ledelse og regnskap i en produksjonsbedrift. Løsningen lar deg organisere et omfattende informasjonssystem som oppfyller bedriftens, russiske og internasjonale standarder og sikrer bedriftens finansielle og økonomiske aktiviteter.

Applikasjonsløsningen skaper et enhetlig informasjonsrom for å vise de finansielle og økonomiske aktivitetene til en bedrift, som dekker de viktigste forretningsprosessene. Samtidig er tilgangen til lagret informasjon tydelig avgrenset, samt muligheten for visse handlinger avhengig av ansattes status.

Ved bedrifter med holdingstruktur kan et felles informasjonsgrunnlag dekke alle organisasjoner som inngår i bedriften. Dette reduserer arbeidsintensiteten til journalføring betydelig på grunn av gjenbruk av vanlige informasjonssett av forskjellige organisasjoner. Samtidig opprettholdes ende-til-ende-styring og regulert (regnskap og skatt) regnskap for alle organisasjoner, men regulert rapportering genereres separat for organisasjoner.

Faktumet om en forretningstransaksjon registreres én gang og gjenspeiles i styring og regulert regnskap. Det er ikke nødvendig å legge inn informasjon på nytt. Midlene for å registrere en forretningstransaksjon er et dokument, og for å fremskynde arbeidet, brukes mekanismer for å erstatte "standard" data og legge inn nye dokumenter basert på tidligere innlagte.

I den anvendte løsningen brukes følgende forhold mellom ulike regnskapsdata:

• uavhengighet av ledelses-, regnskaps- og skatteregnskapsdata;
• sammenlignbarhet av styrings-, regnskaps- og skatteregnskapsdata;
• sammenfall av sum og kvantitative estimater av eiendeler og forpliktelser i henhold til styrings-, regnskaps- og skatteregnskapsdata, i fravær av objektive årsaker til deres avvik.

Data som legges inn av brukere kontrolleres raskt av applikasjonsløsningen. Således, når du registrerer en kontantbetaling, vil systemet sjekke tilgjengeligheten av midler, under hensyntagen til eksisterende forespørsler om utgiftene deres. Og når du registrerer forsendelsen av produkter, vil systemet sjekke statusen til gjensidige oppgjør med mottakeren av varene.

Applikasjonsløsningen kommer med et sett med grensesnitt, som gir hver bruker prioritert tilgang til dataene og mekanismene til applikasjonsløsningen han trenger.

Regulert (regnskap og skatt) regnskap for organisasjoner utføres i nasjonal valuta, mens for ledelsesregnskap for virksomheten som helhet kan enhver valuta velges. Ulike organisasjoner av en enkelt informasjonsbase kan bruke forskjellige skattesystemer: i noen organisasjoner - et generelt skattesystem, i andre - et forenklet system; Ulike skatte- og regnskapsprinsipper kan brukes. I tillegg kan et beskatningssystem i form av en enkelt skatt på beregnet inntekt brukes på visse typer aktiviteter i en organisasjon.

I tillegg til ledelse og forskriftsregnskap kan du føre regnskap i henhold til internasjonale standarder for finansiell rapportering (IFRS). For å redusere arbeidsintensiteten gjennomføres regnskapsføring under IFRS non-operativt ved bruk av omregning (omberegning) av data fra andre typer regnskap.

Når du utvikler "1C: Manufacturing Enterprise Management 8"-løsningen, både moderne internasjonale bedriftsstyringsteknikker (MRP II, CRM, SCM, ERP, ERP II, etc.) og erfaringen med vellykket automatisering av produksjonsbedrifter akkumulert av 1C og partnerbedrifter ble tatt hensyn til fellesskapet. Spesialister fra selskapene "ITRP" (produksjonsstyring) og "1C-Rarus" (regnskap i henhold til IFRS) deltok i design og utvikling av konfigurasjonen. På metodiske spørsmål om implementering av ledelse, finansiell regnskap og rapportering under IFRS, gis konsulentstøtte av det verdenskjente revisjons- og konsulentselskapet PricewaterhouseCoopers.

Løsningen «1C:Manufacturing Enterprise Management 8» ble utviklet på den moderne teknologiplattformen «1C:Enterprise 8». I tillegg til plattformen inkluderer programvarepakken "Manufacturing Enterprise Management"-konfigurasjonen.

Høy pålitelighet og ytelse av applikasjonsløsningen, skalerbarhet, konstruksjon av geografisk distribuerte systemer, og integrasjon med andre informasjonssystemer sikres. Den interne strukturen til applikasjonsløsningen er helt åpen for studier og tilpasning til bedriftens spesifikke behov.

1C-selskapet sluttfører og utvikler "Manufacturing Enterprise Management"-konfigurasjonen for å reflektere endringer i lovgivningen og utvide funksjonaliteten. Sørget for rask oppdatering av installerte applikasjonsløsninger. 1C og partnerne tilbyr et teknisk støttesystem på flere nivåer.

"1C: Manufacturing Enterprise Management 8" er flaggskipsapplikasjonsløsningen til 1C-selskapet med det bredeste spekteret av funksjonalitet. Det generelle konseptet for løsningen er illustrert av diagrammet.

Alle automatiseringsmekanismer for applikasjonsløsninger kan deles inn i to store klasser:

• mekanismer for å opprettholde virksomhetens operasjonelle aktiviteter;
• Områder som tilhører operativ virksomhet kan skilles ut i hver type regnskap (med unntak av regnskap etter IFRS).

I tillegg er applikasjonsløsningen delt inn i separate undersystemer som er ansvarlige for å løse grupper av lignende problemer: et kontantstyringsdelsystem, et personellstyringsundersystem, et regnskapsundersystem, etc. Denne inndelingen er en viss konvensjon som gjør det lettere å mestre applikasjonsløsningen . I brukernes nåværende arbeid merkes grensene mellom delsystemer praktisk talt ikke.

Den siste utgaven av Manufacturing Enterprise Management-konfigurasjonen, som er nummerert 1.3, viser tydelig fordelene med den nye versjonen 8.2 av 1C:Enterprise-plattformen. Konfigurasjonen kan brukes i normal applikasjonsmodus, kjent for brukere av tidligere utgaver.

"1C:Manufacturing Enterprise Management 8" kan brukes i en rekke avdelinger og tjenester til produksjonsbedrifter, inkludert:

• direktorat (generaldirektør, finansdirektør, kommersiell direktør, produksjonsdirektør, sjefingeniør, personaldirektør, IT-direktør, utviklingsdirektør;
• produksjon verksteder;
• produksjons- og ekspedisjonsavdeling;
• sjefdesigneravdeling;
• Sjef teknologiavdeling;
• sjef mekaniker avdeling;
• salgsavdeling;
• logistikk (forsyning) avdeling;
• markedsføringsavdeling;
• varehus for materialer og ferdige produkter;
• regnskap;
• Human Resources Department;
• avdeling for arbeidsorganisasjon og sysselsetting;
• IT-tjeneste;
• administrativ og økonomisk avdeling;
• kapital konstruksjon avdeling;
• informasjon og analytisk avdeling;
• avdeling for strategisk utvikling.

Det forventes at implementeringen av applikasjonsløsningen vil ha størst effekt hos virksomheter med en arbeidsstyrke på flere titalls til flere tusen personer, med titalls og hundrevis av automatiserte arbeidsstasjoner, samt i holding- og nettverksstrukturer.

"1C:Manufacturing Enterprise Management 8" gir:

• for ledelsen av bedriften og ledere med ansvar for forretningsutvikling - gode muligheter for analyse, planlegging og fleksibel forvaltning av selskapets ressurser for å øke konkurranseevnen, ledere av avdelinger, ledere og ansatte som er direkte involvert i produksjon, salg, forsyning og andre aktiviteter støtte produksjonsprosessen - verktøy, slik at du kan øke effektiviteten av det daglige arbeidet i dine områder;
• ansatte i bedriftens regnskapstjenester - verktøy for automatisert regnskap i full overensstemmelse med juridiske krav og bedriftsstandarder til bedriften.

Produksjonsregnskap og kostnader som hovedfag for studien

Hovedkomponenten i å lede en produksjonsbedrift er produksjonsregnskap.

Produksjonsregnskap er en kompleks og interessant teknologi, med egne metoder og teknikker. Produksjonsregnskapets oppgave er å ta hensyn til hele prosessen med kostnadstransformasjon: kostnadene endrer karakter, smelter sammen, splitter, transformerer på ulike måter under produksjonen, dvs. Emnet for produksjonsregnskap er objekter i dynamisk endring. For eksempel gir produksjonsregnskap svar på spørsmålet: hva er kostnaden for et produkt hvis produksjonen krevde et visst beløp av påløpte kostnader nr. 4, bestående av deler kostnader nr. 1 og nr. 2 og fullførte kostnader nr. 3. Hvorfor deler? Fordi for eksempel materialer av et visst stort volum kjøpes, og først må du beregne hvilken del av dette totale volumet av materialer som ble brukt per produksjonsenhet. Det samme gjelder mange andre kostnader - strøm osv. I dette tilfellet er det nødvendig å ta hensyn til hele historien om overgangen av kostnader gjennom produksjonen - fra det øyeblikket kostnaden oppstår i regnskapet til den er inkludert i kostprisen og solgt som en del av produktet, og dens forekomst i regnskapsføring og inkludering i kostprisen kan være i ulike rapporteringsperioder.

Installasjon og lansering av mykstarteren

For å fungere trenger vi 1C 8.2-plattformen. Utgivelse UPP kan hentes fra en hvilken som helst siste utgave 1.3.
Vi vil jobbe med "demo"-databasen. I databaseinnstillingene velger du "Tykk klient" som hovedstartmodus. Resten av innstillingene kan stå som standard.

For de som ennå ikke er kjent med 8.2-plattformen, vil vi gi en kort referanse til begrepet "tykk klient".
En tykk klient i en klient-server-arkitektur er en applikasjon som gir (i motsetning til en tynn klient) avansert funksjonalitet, uavhengig av den sentrale serveren. Ofte er serveren i dette tilfellet bare en datalagring, og alt arbeidet med å behandle og presentere disse dataene blir overført til klientens maskin.
Fordeler med en feit klient
Den tykke klienten har et bredt spekter av funksjonalitet, i motsetning til den tynne klienten.
Flerbrukermodus.
Gir muligheten til å jobbe selv når kommunikasjonen med serveren blir avbrutt.
Har muligheten til å koble til banker uten å bruke Internett.
Høy ytelse.
Feil
Stor distribusjonsstørrelse.
Mye av en klients ytelse avhenger av hvilken plattform den ble utviklet for.
Når du jobber med det, oppstår det problemer med ekstern tilgang til data.
En ganske kompleks installasjons- og konfigurasjonsprosess.
Kompleksiteten ved oppdatering og den tilhørende irrelevansen til data.

Når du starter den installerte demodatabasen, velg brukeren "Abdulov", han har alle rettigheter. Det er ikke nødvendig å angi et passord.

For å studere UPP, når du først starter, redefiner "Abdulov"-brukergrensesnittet til "Full": meny "Brukere - Brukere - Administrasjon - Abdulov - dobbeltklikk for å åpne Abdulov-skjemaet - feltet "Hovedgrensesnitt" - Fullstendig - knappen Ta opp og lukk." Klikk deretter på "Bytt grensesnitt"-knappen i verktøylinjen og velg alternativet "Full".

Om begrepene "Enterprise" og "Organisation", "Regulated" og Management Accounting. Et foretak er en samling av alle organisasjoner som det oppbevares journal over i databasen. « Regulert regnskap«bestemmes av det faktum at reglene for dets oppførsel er fastsatt ved lov. " Økonomistyring"Hver virksomhet kan ha sine egne regler for driften er ikke regulert på noen måte og bestemmes av ledelsen i en bestemt virksomhet. Konfigurasjonen av inneholder en viss visjon om hvordan det er best (mer praktisk, mer visuelt, mer rasjonelt) å utføre administrasjonsregnskap, men hver spesifikke virksomhet kan ha sin egen visjon om styringen på grunn av det faktum at det ikke er ensartet regler og standarder, og i dette tilfellet må det endres. I den typiske konfigurasjonen av UPP er administrasjonsregnskap faktisk basert på kravene til primært regnskap, mens rapportering i administrasjonsregnskap er rettet mot å realisere behovet for planlegging av innkjøp, kostnader mv. Gjennomføringen av ledelsesregnskap bruker ikke prinsippet om dobbel bokføring, d.v.s. for eksempel kan du kapitalisere noe "ut av ingensteds", og det blir ingen gjeld osv. Regulert regnskap gjennomføres for hver organisasjon separat. Ledelsesmessig- delvis for virksomheten som helhet.

Om internasjonalt regnskap. Innledningen slo fast at det er mulig å opprettholde internasjonale rekorder i UPP. Det er verdt å merke seg at dette alternativet bare vises hvis batchregnskap er spesifisert i regnskapspolicyinnstillingene. Hvis (se i grensesnittet "Regnskapsansvarlig" i menyen "Regnskapsinnstillinger - Regnskapsinnstillinger") du velger avansert kostnadsregnskapsanalyse (i stedet for batchregnskap), vil det ikke være mulig å opprettholde internasjonalt regnskap.

Begreper som brukes, betegnelser på objekter som 1C opererer og som må forstås når man arbeider med databasen

• Kataloger
• Overføringer
• Konstanter
• Planer for typer beregninger
• Karakteristiske typeplaner
• Register over opplysninger
• Dokument
• Akkumulasjonsregister
• Kontooversikt
• Rapportere
• Behandling

Kataloger

En katalog er en samling av forskjellige betydninger for noe. Katalogen består av Katalogelementer. Hver verdi av et katalogelement er preget av et gitt sett med parametere. Vanligvis er en av parameterne til et katalogelement ikke-repeterende - for hvert element i katalogen er verdien unik. Vanligvis er dette ordbokelementkoden. Vanligvis fylles katalogen på, dvs. Du kan legge til nye elementer til den mens du jobber med databasen (det finnes også kataloger som ikke er oppdatert, vanligvis en slags klassifiseringsverktøy lastet ned fra andre steder).
Kataloger er nyttige fordi de lar deg fylle ut dokumenter mange ganger raskere, mens elementet vil bli navngitt og presentert det samme overalt når du har satt parameterne til elementet, kan du bruke dem der det er nødvendig.

Hvert katalogelement er et objekt som kan refereres fra andre steder. For eksempel er det en slik katalog "Motparter":


La oss si at du må legge inn data om neste ankomst av varer og tjenester i databasen. I stedet for å skrive navnet på motparten "InnoTrade LLP" på riktig sted og angi alle dens egenskaper som kan kreves for å behandle kvitteringen, vil det være nok å velge det riktige elementet i "Motparter"-katalogen.

Eller, for eksempel, det er en slik katalog - "Valutaer":

I stedet for å skrive navnet på valutaen og angi kursen i hver kvittering, kan vi ganske enkelt velge verdien av valutakatalogen på riktig sted:

Informasjonsregistre

Et informasjonsregister er en type informasjonslagringsenhet som ligner veldig på en katalog. Men i motsetning til en katalog, kan ikke en linje i informasjonsregisteret spesifiseres som et objekt – en registerlinje kan ikke refereres, slik som for eksempel en spesifikk motpart i katalogen "Motparter". Men i informasjonsregisteret kan du for eksempel lagre endringshistorikken til et element i katalogen. For eksempel er historikken for endringer i verdiene til elementene i "Valuta"-katalogen lagret i informasjonsregisteret "Valutakurser":

Ved å lagre valutahistorikk i "Valutakurser"-registeret, er det ikke nødvendig å angi kursen mange ganger for hver kvittering. Programmet selv vil bestemme det, om nødvendig, etter dato.

Overføringer

Oppregning er et spesielt tilfelle av en katalog. En oppregning er et gitt fast sett med verdier for noe. I motsetning til en katalog, har hver oppregningsverdi ingen ekstra parametere.

Konstanter

En konstant er verdien av noe, vanligvis bestemt når du begynner å jobbe med databasen en gang for alle. Spesielt er regnskapspolicyinnstillinger lagret i SCP-konstanter.

Planer for typer beregninger

En spesiell type katalog som beskriver algoritmene for periodisering og fradrag, og annen informasjon som er nødvendig for å beregne periodiseringer og fradrag.

Karakteristiske typeplaner

En spesiell type katalog som beskriver noe tilleggsinformasjon som databaseobjekter inneholder.

Dokumentasjon

Et dokument er et middel for å legge inn data, behandle innlagte data med evnen til å ta hensyn til eksisterende data og konvertere eksisterende data, under hensyntagen til inndataene, til en informasjonsdatabase.

Dokumenter kan deles inn i flere typer:

• som gjenspeiler faktum av økonomisk aktivitet - for eksempel et registreringsdokument i databasen for mottak av varer og tjenester (som et resultat av dokumentet må varer posteres på lageret, en gjeld må vises til leverandøren, mva må registreres , transaksjoner må registreres, etc.) eller "Rapport"-dokumentet produksjon per skift" (registrerer faktum om produksjon av produkter, deres flytting til lageret, registrerer transaksjoner, etc.)
• forskriftsdokumenter - dokumenter som utfører handlinger som må utføres med en gitt frekvens - for eksempel beregne avskrivninger eller beregne lønn, reflektere lønn i regnskap, beregne produksjonskostnader, betale ned produksjonskostnadene, avslutte året (med balanse arkreform), fordele materialer til produksjon, fordele kostnader m.m.
• planleggingsdokumenter - registrering av faktum om planlegging av noen hendelser, registrering av planlagte indikatorer (salgsplan, produksjonsplan, produksjon etter skift, anskaffelsesplan, kjøperordre, leverandørordre, produksjonsordre, ordre for vedlikehold av anleggsmidler)
• ledere - legges inn for å kontrollere arbeidet med andre dokumenter (for eksempel å sette rabatter - dokumentet spesifiserer betingelsene for å gi rabatt, slik at hvis kjøperen når disse betingelsene, får han automatisk rabatt)
• inventar - dokumenter for avklaring, oppdatering av saldoer, for eksempel saldoer av pågående arbeid eller fiksing av saldoer av mangelfulle kostnader (merk: i SCP-konfigurasjonen skriver ikke inventardokumenter informasjon i registeret, men lagrer det bare i seg selv).

Akkumulasjonsregistre

Akkumulasjonsregistre er hovedlagringen av kvantitative og totale data i databasen. Hvert av akkumuleringsregistrene lagrer sin egen spesifikke informasjon. Akkumulasjonsregistre kan deles inn i grupper etter hvilken type informasjon som er lagret:

• Anleggsmidler
• Produksjon
• Lager

Dessuten kan disse dataene lagres i forskjellige registre avhengig av regnskapsdelen, for eksempel registeret Produksjonsfeil (internasjonalt regnskap), Produksjonsfeil (regnskap), Produksjonsfeil (skatteregnskap).

Fra synspunktet om metoden for lagring av informasjon er akkumuleringsregistre gjenværende Og omsettelig.

Restakkumuleringsregistre er utformet for kun å lagre rester til enhver tid. Aktuelle registre lagrer data om hvordan saldoen har endret seg over tid, d.v.s. i dette øyeblikket ble så mye mottatt som et resultat av en slik og en handling, i det øyeblikket gikk så mye tapt som et resultat av en annen handling. Sirkulerende registre lar deg analysere historien til endringer i en mengde eller mengde over en tidsperiode i sammenheng med visse parametere. For eksempel vil et salgsregister vise hvor mye og for hvor mye et spesifikt produkt ble solgt til hvilke motparter over en viss tidsperiode.

Informasjon dukker opp i akkumuleringsregistre ved arbeid med dokumenter, d.v.s. dokumentene satte det der.

Kontooversikt

En typisk UPP-konfigurasjon inneholder fire kontoplaner (og følgelig 4 regnskapsregistre - fysisk er informasjon om kontoplaner lagret i de tilsvarende regnskapsregistrene):

• Budsjettering
• Internasjonal
• Avgift
• Selvbærende

Fordi Ved implementering av ledelsesregnskap overholdes ikke prinsippet om dobbel oppføring, da er det ikke nødvendig med en kontoplan for det. Følgelig, i standardkonfigurasjonen av SCP, dannes det ikke en styringsbalanse. For å gjøre dette kan du enten endre konfigurasjonen, eller, som er å foretrekke, bruke budsjetteringsundersystemet (det lar deg lagre svært forskjellig informasjon, du kan lage et spesielt scenario "Administrasjonsbalanse" og, ved å bruke administrasjonsregnskapsdata, angi informasjon i henhold til dette scenariet for til slutt å få en ledelsesbalanse, men mer om det senere)

UPP inneholder informasjon som kun lagres på kontoplanen (for eksempel informasjon om 80-90 kontoer, data om startkostnad for immaterielle eiendeler, anskaffelse av immaterielle eiendeler (konto 08.05), Utførelse av forskning, utvikling og teknologisk arbeid (konto 08.08 ), FoU-utgifter, deler av utgiftene til 29. konto etc.), det er også opplysninger som kun lagres i akkumuleringsregistre (alt som gjelder planlegging, bestillinger, reservasjoner etc.) og det er opplysninger lagres både på kontoplanen og i akkumuleringsregisteret (lagerregnskap, kostnadsregnskap etc.). Merk. Eksempler i parentes er gitt i avsnittet "regnskap". De samme funksjonene finnes i andre typer regnskap.

La oss se på et eksempel. Åpne dokumentet "Mottak av varer og tjenester" - menyen "Dokumenter - Innkjøpsstyring - Mottak av varer og tjenester". Åpne for eksempel det første dokumentet. Se på innleggene ved hjelp av ikonet Vær oppmerksom på hva analysekonto 10 har: dvs. Etter at kvitteringen er behandlet vil informasjon om varen og lageret lagres på kontoplanen.

Se nå på bevegelsene til dokumentet ved å bruke knappen "Go – Dokumentbevegelser etter registre":

En rapport om dokumentbevegelser åpnes. Du kan skjule gruppetreet ved å klikke i rapportfeltet og deretter trykke samtidig på tastekombinasjonen "Ctrl + Shift + MINUS-tasten i NumLock-tastaturdelen." Se på (utvid) gruppen "Akkumulasjonsregister "Vareparti på lager (regnskap)"":

Vær oppmerksom på detaljene som er sirklet inn - denne analysen var ikke på kontoplanen. Men det er på dette akkumuleringsregisteret.

Det er dokumenter som korrigerer kun oppføringene i kontoplanen, og det finnes så å si fullverdige dokumenter som retter opp all nødvendig informasjon, inkludert avanserte analyser i registre.

Du må forstå at fullverdige dokumenter registrerer informasjon først og fremst i registre, og bare utdragene av denne informasjonen som kreves for balansen er skrevet på kontoplanen. I tillegg benytter alle beregninger som kreves «as you go» alltid reskontrodata, og kun resultatene av disse beregningene kan registreres som oppføringer i kontoplanen. Følgelig, hvis du korrigerer kun kontoplantransaksjoner, dette betyr ikke at alt blir bedre overalt av seg selv, fordi... ingenting vil komme inn i registrene med avansert analyse. De. alt arbeid skal utføres i passende, «riktige» dokumenter, og ikke ved å justere oppføringer i kontoplanen.
Hvis du derimot begynner å justere oppføringene i kontoplanen manuelt, må du justere dem ytterligere - for eksempel vil dokumentet "Beregning av kostnader" for den kommende måneden ikke ta hensyn til eventuelle transaksjoner som er justert i oversikten over regnskap, det fungerer med registre og skriver kun resultatet til kontoplanen ,- som følge av dette kan arbeidsmengden øke så mye at det blir umulig å bruke programmet.
Før du bruker et dokument, må regnskapsføreren forstå om dette dokumentet kun justerer oppføringer, eller om det korrigerer informasjon der det er nødvendig. For å sjekke kan du bruke rapporten, som allerede er nevnt ovenfor, som åpnes ved å klikke på knappen "Go – Dokumentbevegelser etter registre".

I ekstreme tilfeller, når problemet ikke kan løses med et komplett dokument som finnes i databasen som registrerer informasjon både i akkumuleringsregistrene og i kontoplanen, bør du ikke bare bruke, men også et spesialdokument for å justere akkumuleringsregistrene. Samtidig må du selvfølgelig forstå godt ikke bare hvilke posteringer som skal gjøres på kontoplanen, men også i hvilke akkumuleringsregistre, og hvordan, informasjonen skal rettes slik at justeringen til slutt viser seg å være komplett - dette er en veldig delikat sak og kompleks, det er bedre å stole på det bare til en veldig god spesialist.

Rapporter

En rapport er et middel for å hente informasjon fra en database, behandlet og spesielt utarbeidet i en form som er forståelig, praktisk og kreves av brukeren. Det er mange rapporter i konfigurasjonen, de har alle sine egne formål.

Eksempler på eksisterende rapporter:

• Rapporter generert basert på kontoplandata:
• Omsetningsbalanse
• Sjakkark
• Kontoanalyse osv.

• Regulerte rapporter

I SCP-versjon 1.3.7.1-konfigurasjonen er det ikke tilgjengelig å kalle opp verktøyet for å jobbe med regulerte rapporter i "fullgrensesnittet". Bytt derfor til grensesnittet "Regnskap og skatteregnskap" for å finne det:

I dette grensesnittet er verktøyet for å jobbe med regulert rapportering plassert i "Regnskap"-menyen:

• Rapporter basert på data fra akkumuleringsregistre, informasjonsregistre, kataloger osv. (produktutgang, produksjonsplaner, produksjonsfeil, analyse av tilgjengeligheten av varer på lager, analyse av tilgjengeligheten av midler osv.). Vanligvis, hvis en rapport genereres basert på data fra ett register, inneholder navnet ordet "utsagn". Hvis en rapport genereres basert på data fra flere ulike registre, brukes vanligvis ordet «analyse» i tittelen på rapporten.

• Egendefinerte rapporter.

For avanserte brukere er det en mekanisme for å lage egne rapporter. Vi vil snakke om dem mer detaljert litt senere.

Behandlinger

Prosessering er et 1C:Enterprise-verktøy som brukes til å utføre noe programspesifisert datatransformasjon. I motsetning til rapporter, skriver behandlingen disse konverterte dataene til databasen. For eksempel, i "Nomenclature"-katalogen, må du erstatte personen som er ansvarlig for kjøpet med S.G. Chugunova. på Ubeikin V.Ya. For å gjøre dette kan du bruke "Gruppebehandling av kataloger og dokumenter"-behandling:

Fyll ut behandlingsfeltene som følger:

Og klikk på "Velg"-knappen. Gå deretter til fanen "Behandler":

Velg "Handling" og ny verdi. Og klikk på "Kjør"-knappen. Som et resultat var hele nomenklaturen som den ansvarlige innkjøpssjefen ble tildelt S.G. Chugunova. Det blir en ny leder med ansvar for innkjøp.

Konfigurasjonen inneholder også spesialbehandling som utfører noen rutinehandlinger. For eksempel beregning av produktkostnader utført i henhold til en tidsplan.

Prinsipper for arbeid med dokumenter

I denne delen vil vi se på de grunnleggende prinsippene for å jobbe med dokumenter: opprettelse, registrering, oppbevaring (operativ og ikke-operativ, utsatt), markering for sletting, sletting av dokumenter.

Opprette dokumenter

Et dokument kan lages på forskjellige måter. La oss se på eksemplet på dokumentet "Mottak av varer og tjenester"

Metode 1. - ved å bruke "Add(Ins)"-verktøyet. Oppretting av et nytt dokument kan gjøres ved å klikke på "Legg til"-ikonet fra listen over dokumenter som åpnes direkte fra hovedmenyen til programmet. La oss si at du vil opprette et dokument "Mottak av varer og tjenester". Fra hovedmenyen til programmet kan du åpne en liste over disse dokumentene:

Deretter, i listen over kvitteringer som åpnes, velger du en av metodene sirklet i figuren (de er likeverdige, det samme gjøres):

Som et resultat av dette åpnes et nytt dokument "Mottak av varer og tjenester", og du må fylle ut alle feltene sekvensielt (og ikke glem de forskjellige fanene i dette dokumentet - sirklet inn i en ramme):

Metode 2. - bruk av kopimekanismen. Oppretting av et nytt dokument kan gjøres ved å klikke på "Legg til ved å kopiere"-ikonet:

I dette tilfellet vil dokumentet som markøren er plassert på i listen over dokumenter, kopieres og kopien åpnes. Denne kopien vil allerede ha dokumentfeltene fylt ut. Alt som gjenstår er å redigere dem om nødvendig:

Selvfølgelig er denne metoden oftest mye raskere enn å bare lage et dokument.

Metode 3. - ved å bruke inngangsmekanismen på basen. Du kan opprette et nytt dokument fra basisdokumentet. For eksempel kan "Mottak av varer og tjenester" opprettes ved å legge inn basert på dokumentet "Mottaksordre for varer". I dette tilfellet vil for det første den opprinnelige mottaksordren for varer bli grunnlaget for det opprettede dokumentet "Mottak av varer og tjenester", og for det andre vil den dermed opprettede "mottak av varer og tjenester" automatisk fylles ut med data fra basisdokumentet . For å ringe inndatamekanismen på grunnlag, må du åpne dokumentet "Kvittering for varer" og klikke på inndataikonet på grunnlaget. Dessuten kan det samme gjøres uten å åpne selve "Mottaksordre for varer", men direkte fra listen over "Mottaksordrer for varer", bare ved først å plassere markøren på ønsket dokument. Se figuren, inndatametodene på basen er omringet:

Det opprettede nye kvitteringsdokumentet vil "ta" listen over varer fra den overordnede kvitteringsordren:

Metode 4. - bruk av spesielle behandlinger. Opprettelsen av et nytt dokument kan gjøres automatisk når noen spesiell behandling kjører. Vanligvis i dette tilfellet opprettes mange dokumenter samtidig (behandling er nødvendig for å fremskynde prosessen når en slags massehandlinger eller en gitt sekvens av handlinger er nødvendig). Denne metoden vil bli diskutert mer detaljert senere.

Opptak av dokumenter

Dokumentet skrives til databasen når du klikker på "Skriv"-knappen. Inntil denne knappen trykkes i et nytt dokument, vil ikke dokumentet bli lagret i databasen, og i tilfelle et uventet avbrudd (for eksempel strømbrudd), vil det uregistrerte dokumentet gå tapt. Dette er spesielt viktig å vite når du arbeider med dokumenter som inneholder mye informasjon, for eksempel en stor tabelldel fylt ut manuelt. Skriv ned dokumenter ofte slik at du slipper å legge inn data igjen. På tidspunktet for registrering av et dokument skjer det ingen viktige endringer i databasen som påvirker andre data som ikke er relatert til dette dokumentet, dvs. ved opptak lagres dataene ganske enkelt, og disse dataene lagres kun i dokumentet.

Merk. Det er i opptaksøyeblikket at dokumentet tar plass i databasen på tidslinjen blant dokumenter av samme type. La oss forklare mer detaljert. Se på "fra"-feltet med dato og klokkeslett for dokumentet:

Ved opprettelse av et dokument fylles ikke tiden, men ved opptak fylles den til nærmeste sekund. Samtidig, i samme sekund, kan dokumenter av samme type skrives ned av andre brukere av databasen din (dvs. anta at flere brukere av samme database har klikket på "Skriv"-knappen, hver i sin egen "Varekvittering" "dokument og tjenester", og det skjedde i samme sekund). Hvert av de registrerte dokumentene vil, til tross for samme tid, innta sin egen posisjon innen ett sekund. De. selv innen ett sekund på "tidslinjen" for dokumentoppretting, vil hvert dokument ha sitt eget unike sted - det er når dokumentet er registrert at dette stedet blir tildelt det.

Generelt, avhengig av type dokument, kan det hende at bortsett fra opptaket, er det ikke nødvendig med noe annet, dvs. dokumentet er kun ment for å lagre data i seg selv (*se listen over slike dokumenter nedenfor), men for de fleste typer dokumenter er ikke journalen nok. Faktum er at et dokument generelt sett ikke er den mest praktiske lagringen av informasjon er begrenset.

*Liste over dokumenter som kun er registrert:

«Lov om avstemming av innbyrdes oppgjør», «Fullmakt», «Oppgjørsdokument med motpart (manuell regnskapsføring)», «Forespørsel om informasjonstjenester for skattyter», «Inventar over produksjonsfeil» og alle andre typer inventar, «Uformalisert dokument fra skattemyndigheten», «Ikke-formalisert skattyterdokument», «Kartlegging», «Rapport om skiftsammensetning», «Utdeling av spørreskjema», «Beregning av planlagte produksjonskostnader», «Regulert rapport», « Register over fakturaer", "Faktura for betaling til kjøper", "Faktura for betaling til leverandør" ", "Transportforbindelse".

Utføring av dokumenter

Som allerede nevnt, når du registrerer et dokument, lagres de angitte dataene ganske enkelt i dokumentet. Men for de fleste typer dokumenter er opptak ikke nok, det er også nødvendig å gjennomføre det.

Å legge inn et dokument er en spesiell handling som utføres for å registrere noe informasjon for å beskytte den mot ytterligere utilsiktede endringer. I dette tilfellet kan denne informasjonen enten forbli i selve dokumentet (dvs. dokumentet gjør ikke bevegelser et annet sted, for eksempel i akkumuleringsregisteret), eller registreres i form av dokumentbevegelser et sted: i akkumuleringsregistre, informasjonsregistre , kontoplaner, beregningsregistre mv.

Det vil si at dokumenter som ikke utfører bevegelser noe sted også kan behandles. Vanligvis er poenget med å gjennomføre dem å registrere noe informasjon i et dokument for å forhindre ytterligere endring. I den typiske konfigurasjonen av UPP versjon 1.3.7 utføres bare to typer dokumenter, men ingen bevegelser utføres: "Søknad om åpning av kontoer" og "Angi regnskapsparametere for element."

Operativ og ikke-operativ behandling av dokumenter

Ledende dokumenter kan være operative eller ikke-operative.
En operativ prosedyre er en der muligheten for å gjennomføre det undersøkes. Hva det er?

La oss anta at vi opprettet og registrerte et dokument som øker gjelden til en motpart. La oss anta at det er etablert en viss grense på fordringer hos motparten. La oss si at det gikk et par dager etter at dokumentet ble opprettet og noen skrev inn og postet et annet dokument som øker gjelden til samme motpart, og dette siste dokumentet har brukt opp grensen for denne gjelden. Og her oppstår ulike alternativer for videre utvikling.

Hvis organisasjonen fortsatt ønsker forhindre frigjøring av varer når motpartens fordringer overstiger saldoen, må vi sjekke saldoen ved gjennomføring. Men hvis vi ikke endrer datoen, vil gjelden i henhold til programmet ennå ikke bli overskredet - tross alt vil dokumentet som uttømte det ble lagt inn senere og saldoene for gjensidige oppgjør for dokumentet vårt registrert tidligere være irrelevant. Det er for dette formålet at driftsmekanismen ble introdusert - dvs. flytte dokumentet til slutten av køen av bokførte dokumenter, fordi bare i dette tilfellet kan alle nødvendige kontroller utføres.

En annen måte er om det er viktig for organisasjonen å reflektere faktumet til en forretningstransaksjon nøyaktig når den skjedde. Det vil si for eksempel til tross for at kundefordringer overskrides, varene allerede utgitt og faktisk skylder klienten mer enn det som ble etablert som akseptabelt for ham. I dette tilfellet er det viktig for oss å deaktivere sjekken og la den fortsette. Da vil det være riktig å legge ut dokumentet ikke-operativt, dvs. uten alle disse sjekkene.

I begge tilfeller - både operative og ikke-operative, vil alle nødvendige bevegelser av dokumentet bli utført. Det er imidlertid viktig å forstå det Hvis det utføres ikke-operativt, er det stor sannsynlighet for å innhente irrelevante data i databasen, spesielt på grunn av brukerfeil. La oss se på et forenklet eksempel.

La oss si at det ifølge programmet er 10 enheter av et produkt på lageret. La oss si at det har kommet to bestillinger for utgivelsen av dette produktet: for 7 enheter og for 5 enheter. La oss si at et dokument for utgivelsen av de første 7 enhetene er opprettet, men ikke lagt ut. Så, etter en tid, ble det bokført et dokument for frigivelse av 5 enheter, balansen i henhold til programdata etter denne frigivelsen av varer er 5 enheter. Og nå er det på tide å sende inn et dokument for utgivelsen av de første 7 vareenhetene. Hvis lageret virkelig ikke har syv enheter, er det viktig for oss å prøve å utføre en operasjonell utførelse - bare i dette tilfellet vil programmet utføre en sjekk og spørre brukeren om at det er mangel på varer. Men hva om disse 7 enhetene er fysisk på lageret? De. hva skal du gjøre hvis du trenger å gjenspeile faktum om en fullført forretningstransaksjon? Som allerede nevnt, i dette tilfellet må brukeren behandle dokumentet ikke-operativt, ingen kontroller vil bli fullført, dokumentet vil bli behandlet, bevegelsene vil bli utført, men ifølge programmet saldoen vil være minus to enheter.

Som et resultat får vi et tveegget sverd. På den ene siden kan brukeren slippe produktet, fordi Han har det fysisk. På den annen side har vi irrelevante saldoer. De. Det er åpenbart at det i virkeligheten ikke kan være et minus på to enheter, og mest sannsynlig er det ikke utført en form for kvitteringsdokument.

Hvis alle dokumenter alltid ble utført i tide og alltid raskt, ville dette ikke ha skjedd. Men dette er en menneskelig faktor. Hvis data kunne dukke opp i programmet samtidig med fysiske endringer i samme lager... men dataene må legges inn i programmet av en person, dvs. dette tar også litt tid.

For å oppdatere saldoer er det en mekanisme for repostering av dokumenter. Denne mekanismen lanseres kun i eksklusiv modus, dvs. Brukere vil ikke kunne arbeide med databasen på dette tidspunktet. Men jo lenger dette utsettes, jo større kjede av dokumenter som må gjenopprettes, og jo lengre tid vil det ta. Derfor vil det være optimalt å starte denne mekanismen ganske ofte og regelmessig.

Under driftskontering flyttes dokumentet i tid til siste (nåværende) øyeblikk, dvs. definert som sist i rekken.
Selvfølgelig trenger ikke brukeren spesifikt spore noen form for dokumentkø. Denne sporingen skjer automatisk i programmet. Det er bare viktig for brukeren å forstå at hvis programmet stiller et spørsmål om om dokumentet ikke skal utføres, betyr dette at opptaksdatoen for dokumentet hans ikke sammenfaller med gjeldende dato, og brukeren må bestemme om han godtar å endre denne datoen til den gjeldende. For å sikre at det ikke er noen "interessekonflikt i dokumenter", må brukeren godta at dokumentet hans flyttes i køen og likevel flytte det raskt. Eller brukeren må forstå at ved å godta ikke-operativ behandling, gir brukeren klarsignal for mulig tap av relevans for saldoene (og i dette tilfellet, før eller senere, vil det være nødvendig å gjenopprette ordren og oppdater saldoene, så det er fortsatt bedre å alltid prøve å behandle dokumentene raskt).

Vi har allerede nevnt ovenfor at når du registrerer et dokument, blir det tildelt en posisjon i køen av registrerte dokumenter. Hvis opptaksdatoen ikke er på gjeldende dag, er umiddelbar utførelse umulig, selv om ingen andre dokumenter ble opprettet etter dette dokumentet. Og først må du endre datoen til den gjeldende, ellers vil dokumentet ikke bli behandlet umiddelbart.

Under operasjonell behandling endres ikke datoen lenger, bare tidspunktet for dokumentet endres - det blir det aller siste i køen av dokumenter "på tidslinjen". Som følge av denne forskyvningen i køen kan det hende at et dokument skrevet senere enn det er skrevet før det. Dette spiller imidlertid ingen rolle, fordi... når det dokumentet som er registrert senere også begynner å bli behandlet, vil det på samme måte flytte til slutten av køen - det vil flytte på det tidspunktet det skal behandles - og det vil bli det siste.

Hva vil skje når vi lanserer mekanismen for repostering av alle dokumenter for å oppdatere saldoene? Programmet vil sjekke muligheten for utførelse hver gang og i det øyeblikket for eksempel antall kundefordringer overskrides, vil utførelsen stoppe. Og brukeren vil bli bedt om å løse dette problemet: enten øke lånestørrelsen, eller kreditere et uoppgjort forskudd, eller noe annet ... vi snakker mer om mekanismen for re-postering av dokumenter senere.

I den siste utgaven av «1C: Trade Management» på plattform 8.2 er en ny metodikk for å kontrollere behandlingen av dokumenter implementert: «Mekanismen for dokumentbehandling har blitt fullstendig redesignet i konfigurasjonen. Operasjonell kontroll av resultatene av utførelsen utføres etter dannelsen av bevegelsene, i motsetning til utgave 10.3 (hvor kontroll ble utført før utførelsen). Denne løsningen gjorde det mulig å fullstendig skille utførelseslogikken og kontrolllogikken, og radikalt forenkle den tilsvarende programkoden, som igjen er viktig for å lette konfigurasjonsendringer, redusere antall mulige feil og øke systemytelsen. Ved behov foretas kontroll både ved ompostering med tilbakevirkende kraft og ved annullering av kontering av et bilag. Systemet vil for eksempel ikke tillate deg å kansellere en ordre for forsendelse av varer i den grad den allerede er utført." Det kan forventes at lignende endringer gradvis vil strømme inn i nye versjoner av SCP.

Utsatt behandling og viderebehandling av dokumenter

Som nevnt tidligere, ved kontering av dokumenter, utføres ofte bevegelser i en eller annen form for datalagring - akkumuleringsregistre, informasjonsregistre mv. For å utføre disse bevegelsene, låser dokumenter registertabeller. Hvis det på tidspunktet for publisering av dokumentet vårt, når du prøver å blokkere et register, viser seg at dette registeret allerede er blokkert (det vil si i samme øyeblikk som et annet dokument utfører operasjoner med dette registeret), vil dokumentet vårt ikke være i stand til å blokkere den. Han vil bli tvunget til å vente til registeret er gratis. Ved bokføring av et dokument utføres det oftest bevegelser i et stort antall registre samtidig. Hvert av disse registrene er laget for å lagre en eller annen form for informasjon. Som et resultat er sannsynligheten for at det vil være behov for å vente til en av dem er ledig ganske høy.

Mekanismer for forsinket utførelse og ytterligere utførelse er nødvendig for å redusere til et minimum sannsynligheten for behov for en slik venting på grunn av det faktum at når de slås på, blir bevegelser ikke utført umiddelbart i alle registre der det er påkrevd, men bare i de mest "haster" - dvs. i enkelte registre over drifts- og forvaltningsregnskap. Deretter, i henhold til en tidsplan eller manuelt, lanseres oppfølgingsmekanismen, d.v.s. alle andre bevegelser utføres.

For å aktivere mekanismen for utsatt bokføring, må du opprette en "Forsinket bokføringsinnstilling": "Bytt grensesnitt - Regnskapsansvarlig - Utsatt kontering - Innstillinger for dokumentoppfølging" - Legg til et nytt element, spesifiser navn og metode, for eksempel " krever kun oppfølging» - Så i samme meny «Forsinket postering» - punkt «Liste over organisasjoner for utsatt postering» - legg til en ny linje, angi dato*, organisasjon og nyopprettet innstilling.
*Datoen som er angitt er vanligvis vanlig, dvs. skifter månedlig. De. for mer effektivt arbeid, må du flytte det månedlig til den første dagen i inneværende måned - så ved slutten av hver måned vil brukeren som arbeider med periodeavslutningsdokumenter normalt kunne fullføre dokumentene han trenger og fullføre perioden. 1. Gjennomfører: bevegelser dannes langs deler registrerer
2. Følge opp: danner bevegelser langs resten registrerer

Fra et konseptuelt synspunkt ligner oppfølging som off-line utførelse av batch.

Oppfølging utføres:

Mekanismen er nyttig hvis, når du legger inn og poster primærdokumenter:

• krav til produktivitet Og parallellisme er tøffe
• bevegelser på alle registre er ikke nødvendig "akkurat nå"
• Noe av informasjonen som er nødvendig for dannelsen av bevegelser kan være ukjent - de vil bli kjent senere.

Mekanismen gjelder ikke for alle dokumenter, men kun for gigantisk, lagt inn samtidig av et stort antall brukere.

Utsatt kontering brukes ikke for dokumenter som:

• er introdusert sjelden
• det er viktig å gjennomføre med en gang på tvers av alle registre

For en liste over dokumenter som det gjelder utsatt kontering for, se.

Hvordan betjene mekanismen

Mekanismen "Forsinket sending av dokumenter" er valgfri. Bruken kan tilpasses ned til organisasjonen i skjemaet. Utsettelse er gyldig fra angitt dato.

Hvordan dokumenter vil bli bokført avhenger av plasseringen av dokumentdatoen i forhold til startdatoen for den utsatte bokføringen:

Det er fornuftig å bruke forsinket kontering i en periode hvor det skjer intensiv innføring av primærdokumenter. Derfor anbefales det å sette startdatoen for den utsatte konteringen i begynnelsen av måneden som primærbilagene legges inn for.

Ytterligere dokumentasjon utføres iht. Den kan startes enten automatisk i henhold til en tidsplan eller manuelt.

Det er fornuftig å starte ytterligere behandling etter slutten av intensiv inntasting av primærdokumenter. Før du starter oppfølging bør du forsikre deg om at du kjenner alle data for å reflektere dokumenter i regulert regnskap.

Hvis dataene som påvirker refleksjonen av bilag i regulert regnskap etter endt tilleggspostering er endret (for eksempel standard kontoinnstillinger), bør du repostere alle bilagene. Dette kan gjøres ved å velge riktig fullføringsmetode i.

Oppfølgingen må fullføres før oppstart av regulatoriske prosedyrer for lukking av måneden (se diagrammet for prosedyren for ”lukking av måneden”).

Etter at den intensive innføringen av bilag for perioden er fullført og dokumentene er behandlet, anbefales det å flytte startdatoen for den utsatte konteringen frem til begynnelsen av neste måned.

Beskrivelse av mekanismen

Registre, bevegelser langs som dannes ved kontering av et dokument

Hvis det brukes forsinket kontering, genereres bevegelser i de samme registrene som i "full" posteringsmodus når "Reflekter i eks"-flagget er satt. regnskap". Vanligvis brukes disse registrene til å ta operative beslutninger.

Det er funksjoner for "Kostnadsregnskap"-registeret: bevegelser dannes kun når du poster "produksjons"-dokumenter, dokumenter "Mottak av varer og tjenester", "Forhåndsrapport". Ved kontering av alle andre dokumenter genereres det ikke bevegelser i dette registeret.

Ved utføring av dokumenter er ikke dannet bevegelser gjennom registre som ikke brukes til å ta operative beslutninger:

Solgte varer

Salgskostnad

Utsatt uforenlig med moduser:

• Avskrivning av partier ved bokføring av dokumenter

  Fastsettelse av forskudd ved utføring av dokumenter.

Disse modusene brukes når

ingen ytelsesproblemer

det er ikke noe mål å sikre fleksibilitet i regnskapet

Jo høyere prioritet er å få "nøyaktige data med en gang."

Det vil si at forsinket utførelse ikke er nødvendig når du bruker slike moduser.

Kansellering av kontering (distribusjon) av dokumenter

Etter å ha lagt ut et dokument, kan du avbryte det ved å bruke ikonet

Når du avbryter innlegging, blir dokumentet igjen tilgjengelig for endring, og alle tidligere utførte bevegelser blir slettet (eller blir inaktive). Deretter kan dokumentet bokføres på nytt (evt. operativt, med forskyvning på tidslinjen, eller ikke-operativt, dvs. uten å endre dato og klokkeslett).

Sletting av dokumenter

I tilfellet når brukeren bestemmer at for eksempel dokumentet han skrev inn ikke er nødvendig, kan han slette det. Dokumenter slettes med et slettemerke. Deretter kan du kjøre «Slett merkede objekter»-behandlingen og slette den permanent, men inntil da kan slettemerket fjernes og dokumentet gjenopprettes. Denne flertrinnsslettingen er også nyttig fordi "Slett merkede objekter"-behandlingen utfører datakontroll før sletting og beskytter objekter som brukes andre steder i databasen mot sletting. For eksempel vil det være feil å slette en motpart direkte og umiddelbart hvis det allerede er angitt i noen dokumenter, fordi i dette tilfellet vil integriteten til dataene bli krenket - et slikt dokument vil inneholde en lenke til et "ukjent objekt".

I tillegg kan noen ganger dokumenter slettes "direkte", dvs. med en gang. Vanligvis gjøres direkte fjerning ved behandling: når det er , ville det være logisk at den samme behandlingen kunne slette dem.

****************************************************************************************************************************************

1C UPP 8 er mitt favorittprogramvareprodukt i 8.2-linjen. Programmet viste seg å være multifunksjonelt og overraskende fleksibelt, spesielt etter å ha lagt til den avanserte kostnadsanalysemodusen (ACCA). Et uendelig utvalg av alternativer for å bygge forretningsprosesser. Alle prosjektene ble helt forskjellige. I tillegg har UPP en budsjettblokk – toppen av ledelsesregnskap.

Et av de første spørsmålene som implementere vil avgjøre når det gjelder SCP er kostnadsregnskapsregimet. Hva er mer passende: batchregnskap eller avansert analyse. Hva er forskjellen, hva betyr dette i arbeidet ditt, hva bør du spørre om?

Selve mekanismen ble først og fremst oppfunnet for å løse problemene med kompleks produksjon, med mange omfordelinger og motutgivelser. For å beregne kostnadene inkluderer programalgoritmen dannelsen og løsningen av et system med lineære ligninger. Dette lar deg fremskynde beregningen av komplekse problemer betydelig.

Når du velger den avanserte kostnadsanalysemodusen, endres datalagringsstrukturen i programmet og kostnadsberegningsalgoritmene betydelig. Dessuten brukes RAUZ-mekanismen også til å gjøre rede for beholdning, siden i ideologien for avansert analyse er beholdning også en kostnad.

I den tradisjonelle (batch) regnskapsmodusen lagres kostnadene for varelager og utgifter i de tilsvarende akkumuleringsregistrene: mer enn 30 akkumuleringsregistre, ikke medregnet IFRS.

I avansert analysemodus brukes kun 2 akkumuleringsregistre: "Kostnadsregnskap (styrt regnskap)" og "Kostnadsregnskap (regnskap og kontantregnskap)". Ved dannelse av registerbevegelser overholdes prinsippet om dobbeltinnføring. Du kan finne ut hele veien tilbakelagt av en kostnad gjennom hele bedriften.

I den tradisjonelle modusen opprettholdes kronologien til avskrivninger med en nøyaktighet på opptil et sekund, og i RAUZ-modus - med en nøyaktighet på opptil en måned. Derfor, i avanserte analyser, er kostnaden for vareavskrivning i løpet av måneden alltid den samme, selv når du velger FIFO-metoden.

Ferdige produkter avskrives alltid til gjennomsnittlig kostnad. I tillegg er kostnaden for å avskrive varelager/utgifter for hvert dokument ukjent, siden kvitteringsdokumentet ikke er tatt med i RAUZ. Derfor vil det være nødvendig med ytterligere foredling av mange rapporter, for eksempel "Bruttofortjeneste".

Derfor er bruk av avansert kostnadsanalyse ikke praktisk for bedrifter som er fornøyd med arbeidshastigheten i tradisjonell modus og ikke krever noen global modifikasjon av standardløsningen.