skönhet Pannkakor Frisyr

Företagsbetalningskalender och betalningsplan i "WA: Financier" med exempel. Betalningskalender - ett verktyg för operativ ekonomistyrning Betalningskalender 1s upp

Betalningskalendern i "1C: Accounting 8" visar:

  • planerade ekonomiska kvitton för sålda varor, utfört arbete, tillhandahållna tjänster etc.;
  • planerade beräkningar med leverantörer, betalning av löner, bidrag till budgeten, etc.;
  • sena betalningar med leverantörer och entreprenörer, kunder, anställda, tillsynsmyndigheter, etc.;
  • kontanter på väg– skickas men inte krediteras mottagarens konto;
  • kontosaldon i början och slutet av perioden.

Det planerade datumet för mottagande och utgifter för medel visas i "Betalningskalender" baserat på det förväntade datumet. Det förväntade datumet för mottagandet fastställs i fakturor till kunder och dokument för försäljning av varor, arbeten och tjänster. Förväntat förbrukningsdatum fastställs i fakturor från leverantörer och dokument för mottagande av varor, arbeten och tjänster (Fig. 1-1.1).

Om du inte anger förväntat betalningsdatum kommer uppgifterna från dokumentet inte att ingå i betalningskalendern.

Figurer 1-1.1 - Förväntat betalningsdatum i primära dokument


Data om förväntade betalningar visas i "Betalningskalender" fram till betalning, d.v.s. före bildandet och verkställandet av dokumentet "Kvitto till nuvarande konto" eller "Kontantkvitto (vid kassan)", "Avskrivning från löpande konto" eller "Kontantuttag (från kassan)". Vid partiell återbetalning av förpliktelser visas beloppet på den återstående skulden i tabelldelen av "Betalningskalender".

För att använda planeringsfunktionen, markera lämpliga rutor i avsnittet "Programfunktionalitet"(Fig. 2).


Figur 2 - Ställa in betalningsplanering

Du kan ställa in betalningsvillkor för leverantörer och köpare genom sektionen "Administrering" i underavsnitt "Redovisningsparametrar"(Fig. 3-3.1). De tidsfrister som fastställs i redovisningsparametrarna kan ändras i varje specifik faktura eller dokument för mottagande/försäljning av varor, arbeten och tjänster.

Figurer 3-3.1 - Fastställande av planerade betalningsvillkor för köpare och leverantörer



Tillgång till betalningskalendern ges via sektionen "Till chefen" i grupp "Planera"(Figur 1). Betalningskalendern genereras under en godtycklig period angiven i dagar. Urval är tillgängligt från katalogen "Organisationer". Varje avsnitt är markerat i en motsvarande färg, vilket ger bekvämlighet när du arbetar med tabelldelen av rapporten.


Figur 4 - Betalningskalenderformulär

För att få information om kassatillgodohavanden i samband med kontant- och icke-kontantkonton i ett företag måste du följa hyperlänken "Resten av pengarna". När du går öppnas formuläret "Kassabalanser" för det aktuella datumet (fig. 5), som visar information i samband med kontantkonton, deras placering och valutor.


Figur 5 - Visning av kassatillgodohavanden

Betalningskalendern i 1C: Accounting 8 edition 3.0 innehåller följande avsnitt:

Betalning från köpare

Avsnittet visar information om förväntade kontantinbetalningar (CA). Informationskällan är systemdokumenten:

  • faktura till köparen;
  • försäljning (handlingar, fakturor);
  • tillhandahållande av produktionstjänster;
  • överföring av anläggningstillgångar;
  • överlåtelse av immateriella tillgångar.

Skulder i början av perioden för bildandet av "Betalningskalendern" visas i saldon (Fig. 6).


Figur 6 - Uppgifter om skulder och planerade intäkter från ömsesidiga uppgörelser med kunder

Du kan detaljera information om försenade och planerade kundbetalningar genom att gå till formuläret "Förväntad betalning från kunder" (Fig. 7).


Figur 7 - Visning av förväntad betalning från köpare

Notera! Om en kedja av dokument återspeglades för en affärstransaktion, till exempel Faktura till köparen - Försäljning (handlingar, fakturor), med olika eller identiska data, kommer beloppet att återspeglas när formuläret "Förväntad betalning från köpare" genereras flera gånger enligt olika dokument. I det här fallet, i själva betalningskalendern, kommer beloppet att återspeglas enligt informationen från det första dokumentet i kedjan.

Till exempel, för motparten "BAR Dionysus" matades 2 dokument in i programmet:

  1. Faktura till köparen på 102 500,00 RUB, förfallodatum 28/06/17.
  2. Försäljning (handlingar, fakturor) till ett belopp av 99 000,00 rubel, betalningsfrist 06/29/17.

I "Betalningskalender" återspeglas informationen i dokumentet Faktura till köparen 102 500 RUB. (eftersom det är först i kedjan). Samtidigt, i formuläret "Förväntad betalning från kunder" (formuläret anropas från betalningskalendern) återspeglas båda beloppen (102 500 rubel och 99 000 rubel) enligt två dokument och med olika datum.

I formuläret kan du ändra betalningsvillkoret för motparten. För att göra detta måste du välja Motparten i tabelldelen och klicka "Ändra förfallodatum för betalning". Efter att ha ändrat deadline, klicka på "OK"-knappen och uppdatera formuläret.

Dubbelklicka på en rad "Förväntad betalning från köpare"öppnar basdokumentet för visning och redigering.

I form av "Förväntad betalning från köparen" För att meddela Motparten om en försenad betalning, använd knappen "Påminn". Genom att klicka på denna knapp skapas ett brev till motparten med en betalningspåminnelse.

Övrigt utbud

Avsnittet visar information om pengar i transit, överföringar och försäljning via betalkort (Fig. 8). Informationskällan är följande dokument:

  • PKO och RKO med dokumenttyp "Samling".
  • Debitering från ett löpande konto med vyn "Annan avskrivning". Bokföringskonto 57.22 eller 57.02.
  • "Detaljhandelsförsäljningsrapport" med synen "Betalning för sålda varor med betalkort till ett automatiserat försäljningsställe (detaljhandel)."


Figur 8 - Visning av övriga inkomster

Skatter och avgifter

Avsnittet omfattar inbetalningar till budgeten. Informationskällan är skattebetalningsuppgifter från "Uppgiftslista":

  • skatter;
  • avgifter;
  • försäkringspremie;

Uppgifter skapas automatiskt i systemet utifrån upplupna skatter, upprättade deklarationer och rapporter (bild 9).


Figur 9 - Visar information om skatter och avgifter

Tidsfristerna för att betala skatter och avgifter visas i enlighet med bestämmelserna i gällande lagstiftning.

Notera! Betalningskalendern visar hela beloppet av skatteskulden i det ackumulerade saldot (förfallna + planerade).


Figur 10 - Visar en lista över uppgifter och deras status

Om beloppen för betalningen inte bestäms, visas "–"-tecknet i tabelldelen. I det här fallet innehåller cellen en indikation på vad som är nödvändigt för att fastställa betalningsbeloppet. Genom att klicka på en cell kan du öppna ett formulär för att visa beräkningen och betalningen av motsvarande skatt (Fig. 11).


Figur 11 - Information om beräkning och betalning av inkomstskatt

Betalningar till leverantörer

Avsnittet innehåller information om planerade betalningar till leverantörer. Informationskällan är följande dokument:

  • Faktura från leverantör.
  • Kvitton (handlingar, fakturor).
  • Mottagande av ytterligare utgifter.
  • Kvitto av NMA.

Information om försenade betalningar visas i ingående saldon (bild 12).


Figur 12 - Information om ömsesidiga uppgörelser med leverantörer i "Betalningskalender"

Notera! Om det för en affärstransaktion fanns kedja av dokument återspeglas(till exempel "Faktura till köpare - Försäljning"), men dessa dokument är inte relaterade till varandra(dvs. de angavs inte "på grundval", utan separat), då kommer "Betalningskalendern" att återspegla de uppgifter som anges i alla dokument. De där. Kanske dubblering av register för en affärstransaktion.

Också Betalningsordrar markerade för radering visas i "Betalningskalender". Du kan kontrollera förhållandet mellan dokument från dokumentloggen eller från själva dokumentet med hjälp av formuläret "Länkade dokument".

Om fakturabetalningen visades i databasen och dokumentet "Avskrivning från löpande konto" angavs för hela betalningsbeloppet, tilldelas fakturan statusen "Betalad" och den visas inte i betalningskalendern. Men om dokumentet "Avskrivning från det aktuella kontot" markerades för radering, förblir kontot i statusen "Betalt" och återspeglas inte i betalningskalendern. I en sådan situation, för att fakturan ska återspeglas i betalningskalendern, måste du manuellt ändra statusen på fakturan till "Obetald".

Du kan detaljera information om försenade och planerade betalningar genom att klicka på lämplig hyperlänk till formuläret "Betalning till leverantörer" (Fig. 13).


Figur 13 - Visar information om betalningar till leverantörer

I samma formulär kan du ändra betalningsvillkoret för en motpart eller grupp av motparter. För att göra detta måste du välja lämplig motpart och klicka på knappen "Ändra betalningsfrist". Efter att ha ändrat deadline, klicka på knappen "OK" och uppdatera formuläret (klicka på knappen "Uppdatera").

Genom att klicka på raden "Betalning till leverantörer" öppnas motsvarande grunddokument för visning och redigering.

I form av "Betalning till leverantörer" Du kan skapa betalningsorder genom att klicka på knappen "Skapa betalningsorder". När du klickar på den här knappen visas en betalningsorder för visning och redigering.

Vid skapande av betalningsuppdrag för en grupp av motparter visas en journal i programskärmsformuläret "Postanvisningar". I journalen kan du öppna och redigera redan skapade betalningsuppdrag för relevanta motparter.

Från tabelldelen av "Betalningskalender" kan du öppna dokumentet på grundval av vilket skulden till leverantören reflekterades.

Lön

Avsnittet fylls i baserat på saldot av upplupna men obetalda löner (bild 14). Informationskällan är löneutbetalningsuppgifter från "Uppgiftslista". Uppgifter skapas automatiskt i systemet baserat på dokumentet "Löner".


Figur 14 - Visar löneinformation

Tidpunkten för löneutbetalningar visas i enlighet med bestämmelserna i gällande lagstiftning.


Figur 15 - Visning av löneutbetalningsuppgifter

Notera! Listan över arbetsuppgifter visar löneperiodisering i alla månader då löneutbetalningen skulle ha skett, även om det inte finns något dokument i databasen "Löner".

Om dokumentet "Lön för X månad" var markerat för radering, när du flyttar från listan över uppgifter till "Lön för X månad" från dokumentet "Lön för X månad" tas borttagningsmärket automatiskt bort och det postas.

Om dokumentet "Lön för X månad" inte har bokförts, så bokförs dokumentet "Lön för X månad" automatiskt när du byter från Uppgiftslistan till "Lön för X månad".

Om dokumentet "Lön för X månad" inte har skapats, då när du byter från Uppgiftslistan till "Lön för X månad", skapas och bokförs automatiskt dokumentet "Lön för X månad".

Genom att klicka på cellen där den planerade löneutbetalningen anges kan du öppna ett formulär för att visa beräkning och utbetalning av löner samt betalning av personlig inkomstskatt (Fig. 16).


Figur 16 - Visning av löneberäkning och personlig inkomstskatt

Periodiska betalningar

Detta avsnitt fylls i utifrån uppgifter som utformats enligt reglerna för regelbundna betalningar. Regelbundna betalningar (andra än obligatoriska betalningar och löner) visas här, till exempel: hyra, elräkningar, etc. (Fig. 17).

Intresserad betalningsplan i 1C: Bokföring?

Ta reda på detaljerna för att köpa och implementera detta program!

Diskutera implementering


1. Introduktion

Kontantplanering är en av huvuduppgifterna för management accounting, till skillnad från finansiell redovisning.

Naturligtvis finns det andra betydande skillnader mellan förvaltning och redovisning (olika krav på analyser, för bedömning och omvärdering av tillgångar/skulder, behovet av att skapa reserver etc.), men behovet av att lösa planeringsproblem är det svåraste av dem.
Komplexiteten i planering ligger inte bara i att förbereda planen (beräkna den, forma den enligt olika scenarier), utan det är också nödvändigt:

  • Utför omläggning;
  • Uppdatera planer, överföra justeringar till efterföljande perioder;
  • Genomför en plan - faktaanalys.
Det bör erkännas att i de flesta företag (med 1C för automatisering) utförs inte planering i programmet.
"Vi borde sätta upp bokföring..." - så här argumenterar många.

Bokföringen måste förbättras, ja, men inte på bekostnad av planeringen.
Naturligtvis planerar de fortfarande (men inte i 1C, utan i XLS). Och den allra första huvuduppgiften (som de försöker lösa) är kontantplanering.

  • (1) Strategisk (budgetering);
  • (2) Operationell.
Och om budgetering (naturligtvis med en top-down-strategi för planering) kan göras med XLS, så kan inte operationsplanering göras.
Summan av kardemumman är att oftast arbetar ett minimum av användare (1-2 personer) med budgettabeller. För de flesta företag är antalet budgetposter och andra analyser inte så många. Det vill säga allt kan bearbetas manuellt i XLS.

Men vad gäller operativ planering av d/s är situationen här annorlunda. Det vill säga att det ofta är ett stort antal fakturor att betala, många regelbundna betalningar, förväntade betalningar för kundorder osv.

Och dessutom kan allt detta "bindas upp" till ett stort antal primära dokument med vilka olika användare av programmet arbetar, dokument justeras, situationen förändras, etc.

En annan viktig skillnad mellan verksamhetsplanering och budgetering är att det ofta kommer nerifrån och upp. Det vill säga från ”Begäran om d/s-utgifter”, som alltid fylls i av avdelningsanställda.

Och dessa ansökningar måste följaktligen behandlas i tid, accepteras/avvisas, "schemaläggas" och betalas.

Total: verksamhetsplanering för d/s är den allra första planeringsuppgiften, som bör automatiseras i 1C för alla företag.

Och som ett resultat av planering bör ekonomiavdelningen / finansavdelningen "se" i systemet:

  • När, till vem, från vilket bankkonto/kontanter, för vilket belopp ska betalas;
  • Vad blir kassabehållningen på "sådan och sådan" datum, med hänsyn tagen till aktuella saldon, planerade utgifter och kassakvitton. Den så kallade måste undvikas. "kassaluckor"

    Det vill säga att det finns ett behov av att arbeta med betalningskalendern.

  • Vilken skuld med motparter kommer att vara på de angivna datumen, med hänsyn till planerade betalningar, kvitton och det aktuella saldot av ömsesidiga avvecklingar.

    Det vill säga att det finns ett behov av att arbeta med beräkningskalendern.

Syftet med denna artikel – prata om möjligheterna att automatisera verksamhetsplanering för d/c. Samtidigt kommer en jämförande analys av 3 olika cirkulationskonfigurationer att genomföras (två är standard från 1C, en är specialiserad från företaget wiseadvice).

Var och en av konfigurationerna kan användas för att lösa driftsplaneringsproblem, men ett balanserat val bör göras baserat på omfattningen och omfattningen av ditt projekt.

2. Funktioner hos mjukstartare 1.3

För tillfället har 1C ännu inte släppt den efterlängtade, nya utgåvan av UPP (revision 2). Och av denna anledning kommer vi att fokusera på vad som är tillgängligt - motsvarande delsystem i SCP 1.3:

Det måste noteras att delsystemet "Requests for Expenditure of Cash" uppdaterades i konfigurationen relativt nyligen (2011). Och som ett resultat, i det hanterade gränssnittsläget, dök objektet "Begäran om utgifter d/s/" upp i sektionspanelen.


Om du försöker i en standardkonfiguration, i filläge, att öppna dokumentformuläret "Request for D/s Expenses" (aka, ZRDS), så visas ett fel omedelbart för variabeln "Globala värden" från den allmänna modulen "Arbeta med Allmänna variabler”.

Sådana fel kan dock korrigeras, som de säger: "sedimentet finns kvar." Det vill säga att det finns tillräckligt med "grovheter" i UPP ZRDS-delsystemet.
Möjligheten att skapa ett ZRDS-dokument via en webbläsare är användbar, men i praktiken måste du tänka noga på förenklingen och ergonomin för dokumentets standardform. Detta kommer att vara särskilt viktigt för mobila enheter.

Men vad gäller betalningskalendern, i tunt klientläge, på distans via en webbläsare osv. du kommer inte att kunna använda den. Anledningen är att delsystemet Cash Management inte har uppdaterats på länge och i synnerhet att betalningskalenderrapporten inte bygger på ett datasammansättningssystem. Därför kan denna rapport inte användas i tunna klienter, det finns ingen möjlighet att skapa anpassade inställningar för den.

När man arbetar med ZRDS upptas en viktig plats av regelverket för samordning och godkännande av ansökningar. Beroende på företagets organisationsstruktur och andra affärsegenskaper kan det interna förfarandet för att godkänna ansökningar (godkännandebestämmelser) vara ganska komplext (flerstegs, variabelt, etc.). Så det här är ingen lätt uppgift för automatisering.

I UPP är delsystemet samordning och godkännande implementerat. Det ger ganska flexibla inställningar.

  • Ett godkännande är en bekräftelse på behovet av att betala för ansökan. Typiskt måste godkännandet gå via avdelningschefer, chefer och andra ansvariga personer på företaget.
  • Godkännande är den slutliga bekräftelsen (av kassören) på att ansökan kommer att betalas. I detta fall måste betalningsdatum och vilket bankkonto/kassa som betalningen ska göras från fastställas. Således faller betalningen in i verksamhetsplanen (betalningskalendern).
Det måste noteras att ett antal aspekter av mjukstartarens standardfunktionalitet inte ger vad som krävs under själva implementeringen av delsystemet.
Jag kommer att skriva om dessa "ögonblick" senare, men låt oss nu titta på vilken funktionalitet en typisk konfiguration ger.
  1. Du kan aktivera användningen av applikationsgodkännandemekanismen separat för varje organisation.

  • Det är möjligt att konfigurera sekvensen för applikationen genom rutter och hierarkin av rutter.
  1. Det bör noteras att hierarkin i avdelningskatalogen inte beaktas irna.
  2. Det är också nödvändigt att avbryta att samordningen och godkännandet var tekniskt konstruerade utan användning av en affärsprocessmekanism.

  • Vid varje tillfälle kan du ange en/flera användare för vilka godkännande av applikationen kommer att finnas tillgängligt. Det vill säga att ansökan kan godkännas av vem som helst av dem (den som lyckas göra det först).

  • För varje avdelning kan du tilldela en motsvarande godkännandevägpunkt. Kärnan i detta är detta: när du fyller i en ansökan (ZRDS), måste det centrala federala distriktet (division) anges. Och beroende på den angivna indelningen "hittar" UPP motsvarande godkännandepunkt och "sänder" ansökan om godkännande till denna punkt.

Det är också möjligt att inte ange någon avdelning när godkännandevägen läggs upp. I det här fallet kommer en sådan koordinationspunkt att "tillämpas" på alla CFD:er för vilka motsvarande ruttpunkt inte är specifikt angiven.

  1. Själva godkännandet utförs med hjälp av en speciell bearbetning "Ansökan godkännande"

  1. Analys av den planerade tillgången på medel, betalningsplan och spårning av kassaluckor utförs i rapporten "Betalningskalender".

Utöver den planerade förbrukningen av d/s (ZRDS) kan du även ta hänsyn till det planerade mottagandet av d/s. För dessa ändamål är det tänkt att utarbeta ett särskilt dokument "Planerat inkomstinkomst".


Det bör noteras att även om dokumentet "Planerad mottagning av d/c" har tillstånd (förberedda, överenskomna, etc.), finns det ingen möjlighet att samordna detta dokument (liksom ZRDS). Det vill säga att ändra dokumentstatus endast är möjligt i läget "manuell kontroll".

Och i UPP är det möjligt att ta hänsyn till det planerade mottagandet av kontanter från köpare utan att förbereda dokument "Planerat mottagande av kontanter".

Det vill säga, om "Kundorder" utfärdas för en köpare, så kan detta planerade kvitto ses i en separat rapport "Betalningskalender med hänsyn till beställningar".

  1. Utöver rapporten Betalningskalender finns en rapport för analys av kontanttillgänglighet.

Samtidigt går det att reservera d/s (baserat på ansökningar om utlägg) eller lägga ansökningar mot planerade intäkter.

Det finns även funktionalitet för att stänga ZRDS och planerade intäkter från d/s. För dessa ändamål, i läget "vanlig kund", tillhandahålls dokument "Avslutande av ansökningar om utgifter/kvitton".

Denna funktion stöds dock inte heller i tunn-/webbklientläge.
Här måste du förstå att tekniken "hård reservation" är starkt knuten till kronologin för dokumentinmatning, och detta gör justeringar och omläggning svåra.

Därför lämnas funktionaliteten i UPP snarare som ett "arv från det förflutna", och betalningskalendern bör användas för att analysera tillgängligheten av d/s.


Så vi har övervägt funktionaliteten hos mjukstartaren och nu kommer jag att lista de aspekter av standardkonfigurationen som i praktiken, på projekt, måste ändras:

  1. Enligt dokumentet "Ansökan om d/s-utgifter":
    1. I dokumentet kan du ange "Division" (förresten, i konfigurationen är den betecknad som Central Federal District - centrum för ekonomiskt ansvar). Men det är fullt möjligt att en ansökan lämnas in från en avdelning (CFD), och i det här fallet kommer kostnaderna att behöva hänföras/fördelas ytterligare till en annan avdelning(er) (CFD - ekonomistyrningscenter).

      Möjlighet att specificera digitala funktioner m.m. - frånvarande.

      Det finns ingen möjlighet att ändra rutt eller omdirigera applikationen till andra rutter.

    1. Det finns ingen möjlighet att planera överföring av kontanter mellan löpande konton, från kontot till kassan osv.
  1. Avtalsprocess:
    1. Det är möjligt att koordinera ZRDS, men det finns ingen möjlighet att koordinera det planerade mottagandet av d/s.
    2. I praktiken blir det nödvändigt att genomföra godkännanden för andra anställda. Samtidigt behöver systemet också registrera information om "vem som utförde godkännandet och för vem."

      Möjligheten att installera flera möjliga utförare vid en samordningspunkt är ofta inte lämplig, så denna utförare kan indikeras vid andra stadier av samordning. Som ett resultat kommer allt detta att leda till att den anställde samtidigt kommer att ha både huvudsakliga och indirekta godkännandeuppgifter i listan över förfrågningar om godkännande. Naturligtvis förvirrar detta användaren och är inte bekvämt.

      För att sammanfatta, förmågan att samordna för en annan utförare, förmågan att ange vem som har rätt att samordna för vem som är frånvarande.

    3. I processen för att godkänna ansökningar, när en ansökan skickas vidare för godkännande till nästa längs vägen, efterfrågas funktionen att automatiskt informera (via e-post) nästa utförare, såväl som författaren till ansökan. .
    4. Om författaren till applikationen redan är ansvarig för koordinering/godkännande (i vilket skede av rutten som helst!), så är det ganska logiskt att programmet automatiskt "förkortar" rutten och omdirigerar applikationen till den högsta tillgängliga nivån. Detta föreskrivs dock inte i UPP.
    • Alla ovanstående krav, även om de inte ingår i standardkonfigurationen, är ändå .
  1. Rapporter, åtkomsträttigheter.
    1. Det finns en efterfrågan på möjligheten att begränsa tillgången till applikationer endast för tillgängliga författare/utövare (koordinatorer); av avdelningar som är tillgängliga för användaren.
    2. Det finns ingen rapportering om övervakning (efter dagar och intervall) av faktiska och planerade skulder. Detta gäller både för köpare och leverantörer.
    3. Rapportering och en del av funktionerna lämpar sig inte för att arbeta i tunn-/webbklientläge.
  2. Redovisning av ordinarie avtal och kontrakt.
    1. Det finns ofta situationer då det är nödvändigt att regelbundet betala leverantörer. Till exempel hyresbetalningar m.m.

      UPP speglar det inte automatiskt i betalningskalendern osv. dessa kommande utgifter. Det vill säga att det är nödvändigt att manuellt spåra sådana betalningar och fylla i betalningsförfrågningar, vilket är obekvämt och arbetskrävande.

    2. Avtal med köpare och leverantörer kan ställa villkor för förskottsbetalningsprocent, betalningsvillkor m.m.

      UPP registrerar inte automatiskt all denna information och (som ett resultat) reflekterar den automatiskt i betalningskalendern.

3. Funktioner i UT 11.1

Med lanseringen av den nya konfigurationen "Trade Management Rev.11" har många nya, användbara funktioner dykt upp för uppgifterna med operativ planering och finansiell kontroll.
Det kanske viktigaste i denna del i UT11 (jämfört med UPP 1.3) är mekanismen för redovisning av betalningsplanen. Denna mekanism ”stänger” det som verkligen saknades – automatisering av planering/redovisning enligt vanliga avtal och kontrakt.

I UT11 behöver du alltså inte upprätta dokument alls (om det inte finns något behov förstås) för planering av utgifter och kvitton, och samtidigt kommer betalningskalendern att bildas normalt.

Du kan avbryta att "standardinställningarna" i rapporten "Betalningskalender" inte riktigt motsvarar förväntningarna (som sådan visas inte kalendern), men i användarläget kan du lägga till en gruppering efter "betalningsdatum" och rapporten kommer att genereras i vanlig form.



Rapportens funktionalitet har utökats kraftigt (jämfört med SCP 1.3) på grund av användningen av ett datasammansättningssystem. Nu kan rapporten genereras i en tunn/webbklient, sparas i databasen och tilldelas olika användare de inställningar de behöver.

Förutom att planera konsumtion och mottagande av bohag, har UT11 nu funktionen att planera förflyttning av bohag. För dessa ändamål kan du upprätta dokument "Beställning om flytt av hushåll."

Jämfört med UPP 1.3 för dokumentet "Ansökan om utgifter för kontanter" har antalet övervägda typer av affärstransaktioner ökat:

Det är nu möjligt att godkänna både dokumenten "Ansökan om utgifter för medel" och andra beställningar:

För att analysera skulden efter intervall/deadlines, tillhandahålls rapporten ”Kundreskontra”. Vid behov kan du även skapa en skuldkalender. För att göra detta, i anpassat läge bör du lägga till en gruppering efter betalningsdatum.


Tyvärr ger UT11 (som tidigare) inte möjlighet att analysera skuldkalendern efter leverantörer. UT11 måste dock modifieras för denna uppgift.

För att sammanfatta: nya metodiska lösningar "1C", tillsammans med kapaciteten hos 8.2-plattformen, ger en bra grund för att automatisera uppgifterna för operativ planering och kontroll av d/s.

Men samtidigt måste du förstå att UT11-konfigurationen inte är en komplett, färdig lösning för treasury-automation och finansiell planering.

  • För det första implementerar UT11 i en mycket förenklad form en mekanism för att samordna/godkänna förfrågningar om utgifter och andra d/c-planeringsdokument. Det vill säga, det finns inga routingmekanismer, processen för att godkänna ansökningar reduceras till att helt enkelt ställa in status.
  • För det andra har UT11 inget delsystem för budgetering och (som ett resultat) finns det ingen funktionalitet för att övervaka ansökningar för planerade budgetar.
4. WA Funktioner: Finansiär

Historiskt sett har WA:Financier-konfigurationen utvecklats baserat på Treasury Management-produkten.

Och samtidigt innehåller den nya "Financier"-lösningen från WiseAdvice också:

  • Delsystem för budgetplanering;
  • Undersystem för kontraktshantering;
  • Delsystem för bildande och redovisning av faktiska betalningar;
  • Flexibel, anpassningsbar mekanism för att generera/fylla i dokument baserat på mallar;
  • Flexibelt, anpassningsbart klient-bank-integrationsundersystem.
Låt oss överväga huvudfunktionen hos "WA: Financier" när det gäller treasury - från att ta hänsyn till villkoren för kontrakt till att skapa en betalningskalender.









  1. Under godkännandeprocessen för ansökan kan du inte bara godkänna/avslå dokumentet (som görs i UPP), utan andra funktioner finns också tillgängliga: till exempel skicka ett dokument för revision eller begära ytterligare information. information.

    Hela denna process är automatiserad, därför tillhandahålls rapportering om status för dokumentgodkännandebehandling.




5. Resultat




Slutsatser:

  1. För att automatisera arbetet på finansiella avdelningar, finansavdelningar, organisationer med komplexa organisationsstrukturer. struktur är den lämpligaste lösningen "WA: Finansiär".

    Denna lösning har utvecklats och utvecklats under lång tid, och har därför samlat på sig specifikationerna och kraven från olika finansiella institutioner. avdelningar och finanskassor. De totala arbetskostnaderna för att utveckla lösningen uppgick till mer än 5 000 person/timmar.

    Fördelen med WA: Financier-lösningen är dess avancerade funktionalitet och ett stort antal programinställningar. Således är implementeringen av denna lösning möjlig på kort tid (den så kallade "out-of-the-box-implementeringen") utan ytterligare. utveckling, programmering etc.

    Eftersom lösningen innehåller mekanismer för tvåvägsutbyte med alla huvudstandardkonfigurationer, kommer integrering i den befintliga strukturen (datautbyte med UT, UPP, Kompleksnaya, Bukh-databaser) inte att vara svårt.

  2. För att automatisera ekonomiavdelningen/kassan inom ramen för ett omfattande automationsprojekt den bästa lösningen är baserat på UPP.

    Samtidigt måste du förstå att funktionaliteten hos mjukstartaren kommer att kräva förbättringar.

    Specifikt, ekonomiska krav. avdelningar och treasuries är inte inbäddade i UPP så djupt som görs i separata, specialiserade lösningar.

    Implementeringen av SCP för dessa uppgifter bör därför endast utföras som en del av ett automationsprojekt.

  3. För stora organisationer, för att automatisera finansavdelningen UT11 passar inte.

    I detta beslut finns för det första inga mekanismer för samordning/godkännande av planeringsunderlag.

    För det andra finns det inget undersystem för budgetering och kontroll över genomförandet av budgetar under operativ planering.

    Däremot UT11 perfekt för automation (inklusive driftplanering d/c) liten ekonomisk företagsavdelningar.

Program "Betalningskalender 2.1"
för 1C: Redovisning 8

programvara "SysTecs: Betalningskalender" används för att lösa problem med operativ planering av mottagande och utgifter för kontanter och icke-kontanta medel. Programmet utvecklades på plattformen "1C: Enterprise 8.2" och är fristående konfiguration, som inkluderar följande funktionalitet: planering av mottagandet av medel från kunder, planering av betalningar till leverantörer och andra fordringsägare, underhåll av organisationens betalningskalender i samband med typer av fonder, motparter och kontrakt, samt en klassificerare av föremål för användning av medel. Planeringssystemet bygger på användningen av faktiska bokföringsdata, samt data om förväntade inbetalningar från konton och regulatoriska betalningar. Den operativa intäktsplaneringskretsen ger programanvändare ett effektivt sätt att hantera och kontrollera processen för avräkningar med köpare och kunder.

Funktionsprinciper för programmet "SysTecs: Payment Calendar".

SysTecs: Payment Calendar-programmet är en fristående konfiguration som utökar funktionaliteten hos applikationslösningen 1C: Accounting 8. Programmet kräver inga ändringar av 1C:Accounting-konfigurationen och använder mekanismen för en extern COM-anslutning som tillhandahålls av 1C:Enterprise 8.2-teknologiplattformen för att utbyta information. Denna princip i programmet ger:

  • enkel installation av mjukvaruprodukten;
  • frånvaro av konflikter som uppstår vid sammanslagning av konfigurationer;
  • upprätthålla standard 1C: Procedurer för uppdatering av redovisning och tekniska supportvillkor.

Trots autonomin, på grund av flexibel integration baserad på allmänt erkända öppna standarder och dataöverföringsprotokoll, arbetar användare i ett enda informationsutrymme som om de arbetade i ett enda program.

■ Viktig information

Mjukvaruprodukten är avsedd endast för delning med följande applikationslösningar: 1C: Accounting 8 (utgåvor 1.6, 2.0) och 1C: Accounting KORP, som körs på teknologiplattformen 1C: Enterprise 8.2 inte lägre än 8.2.13.202.

Huvuddragen i programmet

Programmet SysTecs: Payment Calendar tillhandahåller effektiva verktyg för operativ kontroll av kassaflödet i en organisation som möter de verkliga behoven hos små och medelstora företag. Enkelhet och funktionalitet för användargränssnitt, integration med 1C:Accounting-data, flexibla rapporteringsmöjligheter gör att du kan planera mottagandet och utgifterna för pengar, underhålla organisationens betalningskalender.

■ Kassaflödesplanering

Funktionen implementerad i programmet "SysTecs: Payment Calendar" låter dig planera mottagandet av pengar från köpare och kunder med hjälp av en bekväm och informativ planeringsassistent. Alla egenskaper hos kommande kvitton (mottagningsdatum, motpart, belopp etc.) läggs in i programmet med hjälp av planeringsdokument och återspeglas i organisationens betalningskalender. På grund av flexibel integration med 1C:Accounting data implementerar programmet funktioner för att övervaka utförandet av intäktsdelen av betalningskalendern. Information om det faktiska mottagandet av kontanter och icke-kontanta medel från motparter återspeglas i planeringsassistenten och programrapporterna, vilket gör att du snabbt kan övervaka statusen för uppgörelser med kunder och förutsäga dynamiken i kontantkvitton.

■ Betalningsplanering

Programmet "SysTecs: Payment Calendar" ger chefer och företagsledning effektiva verktyg för operativ planering av betalningar i organisationen. Programmet tillhandahåller en bekväm betalningsplaneringsassistent som gör det möjligt för finansiellt ansvarscentrum att generera förfrågningar om betalningar till leverantörer och andra motparter. De genererade ansökningarna, som går igenom godkännandeförfarandet, ingår i utgiftsdelen av organisationens betalningskalender. För att analysera och godkänna applikationer tillhandahåller programmet ett bekvämt och informativt gränssnitt för applikationshantering. Genom att använda programmet "SysTecs: Payment Calendar" har du möjlighet att kontrollera avdelningarnas kontantbehov, hantera betalningar till leverantörer och säkerställa efterlevnad av rutiner för att godkänna betalning av utlägg.

■ Göra betalningar

Funktionerna i programmet "SysTecs: Payment Calendar" möjliggör ytterligare rangordning av godkända betalningsförfrågningar, inklusive dem i dagens betalningsregister. Detta tillvägagångssätt hjälper till att anpassa kontantutgiftsplanen med faktiska saldon på löpande konton. Ansökningar som inte ingår i registret kan skjutas upp till en ny betalningsfrist eller avslås. Baserat på betalningsregistret låter programmet dig generera betalningsdokument (utgående betalningsuppdrag) och överföra dem till 1C: Bokföringsdatabasen. Faktumet att överföra medel till motparter återspeglas i rapporter och assistenter för planering av betalningar och kontanttransaktioner, vilket gör att du kan kontrollera utgifterna för medel och ömsesidiga uppgörelser med leverantörer.

■ Upprätthålla en betalningskalender

All information om faktiska saldon, planerade inbetalningar och utgifter för medel återspeglas i betalningskalenderrapporten, som gör att du snabbt kan övervaka företagets likviditet och använda medel med maximal effektivitet. Analytiskt låter delar av betalningskalendern dig svara på de viktigaste frågorna som berör alla chefer: vem som ska betalas, när och för vad, och från vem och när medlen kommer. Med hjälp av betalningskalenderdata kan du bygga olika kassaflödesprognoser, ändra datum för kvitton, betalningar och samordna dem med motparter, och även förhindra att spendera pengar som överstiger de gränser som fastställts i organisationen.

■ Datautbyte med 1C Accounting

En utmärkande egenskap hos programmet "SysTecs: Payment Calendar" är mekanismen för att utbyta data med 1C: Accounting 8, implementerad med COM-anslutningsteknik. Användningen av denna teknik som tillhandahålls av 1C:Enterprise 8.2-plattformen låter dig kombinera data från redovisningsprogrammet och SysTecs: Payment Calendar-programmet till ett enda informationsutrymme. Detta tillvägagångssätt gör att du smärtfritt kan utöka funktionaliteten hos 1C: Accounting, samtidigt som du behåller bekvämligheten med att arbeta med ett enhetligt informationssystem. Eventuella ändringar av data i ett program blir omedelbart tillgängliga i ett annat och för detta behöver systemanvändare inte utföra några ytterligare åtgärder.

Teknisk support av mjukvaruprodukten

■ Teknisk supporttjänst

Alla registrerade användare av SysTecs produkter tillhandahålls med teknisk support, åtkomst till vilken organiseras via användarens personliga konto på företagets webbplats. Där kan du inte bara ställa frågor av intresse, utan också ge förslag för att utöka programmets funktionalitet. Glöm inte att utvecklingen av en mjukvaruprodukt i första hand är beroende av aktivt användarstöd.

■ Programvaruuppdateringar

När du köper programmet "SysTecs: Payment Calendar" får du ett gratis sex månaders prenumeration på aktuella uppdateringar. Efter att den kostnadsfria sexmånadersprenumerationen löper ut kan du registrera dig för det mest bekväma betalda uppgraderingsalternativet. Du kan se prenumerationsalternativ och priser på programkostnadssidan.

■ Detaljerad dokumentation

Leveransen av mjukvaruprodukten "SysTecs: Payment Calendar" inkluderar en komplett uppsättning dokumentation för att arbeta med programmet. Dokumentationen diskuterar inte bara metodiken för att installera, konfigurera och använda programmet, utan också frågorna om att organisera automatiserade affärsprocesser för betalningskalendern. Delar av dokumentationen är åtkomliga från alla objekt (referensbok, dokument, gränssnitt) i programmet, och det automatiska uppdateringssystemet inbyggt i mjukvarupaketet gör det möjligt att använda den senaste versionen av dokumentationen i ditt arbete.

Demoversion av programmet

Programmet "SysTecs: Payment Calendar" har en fullt fungerande demoversion. Närvaron av en demoversion gör det möjligt att utvärdera effektiviteten av betalningskalendersystemet i verkliga driftsförhållanden och låter dig fatta ett köpbeslut baserat inte bara på presentationsmaterial utan också på din egen erfarenhet av produkten. Vi anser att endast detta tillvägagångssätt är rättvist för kunderna, eftersom det är detta som ger användaren garantier för att automatiseringsscheman och funktionerna för affärsprocesser som ingår i programmet uppfyller kraven för din verksamhet.

Vad handlar den här artikeln om?

Betalningsplan– ett användbart verktyg för finansiärer och förvaltare. Den kan användas för att utföra kassaanalys och planering.

I artikeln kommer vi att titta på:

  • Utformning av en betalningsplan
  • Kontroll av att betalningar genomförs i tid
  • Kontroll av löpande saldon i kassaregister och löpande konton
  • Inställningar för betalningsvillkor mottagna från kunder och överförda till leverantörer
  • Mekanism för beräkning av betalningsdatum för förskotts- och kreditmöjligheter

Tillämplighet

Artikeln skrevs för två upplagor av 1C: Trade Management - 11.1 Och 11.2 . Om du använder dessa utgåvor, bra - läs artikeln och implementera den diskuterade funktionaliteten.

Om du planerar att börja implementera UT 11 kommer troligen en nyare utgåva att användas. Gränssnitt och funktionalitet kan variera.

Därför rekommenderar vi att du går kursen Praktiska uppgifter på nivå 1C: Specialist i UT 11, KA 2 och 1C: ERP 2, detta hjälper dig att undvika misstag och förlust av tid/rykte.

Formulering av problemet

Möbeldesignföretaget är engagerat i partihandel med möbler. Företaget har ett grossistlager från vilket varor skickas.

För alla kunder, vid beställning, används en förskottsbetalning på 10 % av dess belopp tills beställningen är säkerställd. För resten (90 % av beställningsbeloppet) ges en respitperiod på 2 dagar.

För att återbetala betalningen till leverantören av Möbelservice ges vårt företag en frist på 3 dagar efter mottagandet av varorna.

Ledningen skickar med jämna mellanrum fram förfrågningar i förväg om emission av medel till ansvariga personer. Det vill säga att det skapas en applikation idag för att betala pengar imorgon – med planerat betalningsdatum.

Det är också nödvändigt att planera ett schema för framtida inkommande betalningar (till exempel att få ett lån).

Alla företagsprocesser återspeglas med hjälp av programmet 1C: Trade Management 11.

Vad du behöver få

Demonstrera funktionalitet som låter dig analysera fonder, skapa ett betalningsschema och övervaka dess genomförande i 1C: Trade Management 11-programmet.

Löser problemet med betalningskalendern

Låt oss först skapa möbeldesignorganisationen i databasen.

Eftersom vårt företag bara använder en organisation kommer vi inte att sätta flaggan "Flera organisationer" i avsnittet "Administration" - "Organisationer och fonder" (i UT 11.2 är detta avsnittet "Forskningsdata och administration" - "Företag").

För att skapa en organisation, låt oss gå till avsnittet ”Reglerings- och referensinformation” – ”Inställningar och referensböcker” – ”Information om organisationen” (i UT 11.2 är detta avsnittet ”Forskningsdata och administration” – ”Information om företaget ”).

Vi kommer att fylla i all nödvändig information. Låt oss spela in organisationens kort genom att klicka på knappen "Spela in och stäng".

Företaget använder ett grossistlager.

Följaktligen, i avsnittet "Administration" - "Lager och leverans" är det inte nödvändigt att inkludera flaggan "Flera lager" (i UT 11.2 är detta avsnittet "Referensdata och administration" - "Lager och leverans").

Låt oss gå till avsnittet "Reglerings- och referensinformation" - "Inställningar och referensböcker" - "Ställ in lagerbokföring" (i UT 11.2 är detta avsnittet "Stamdata och administration" - "Information om företaget" - "Konfigurera lagerbokföring").

Vi kommer att fylla i all nödvändig information och skriva ner ett lagerkort.

Företaget använder kundorder och beställningar till leverantörer.

I avsnittet "Administration" - "CRM och försäljning" (i UT 11.2 är detta avsnittet "Forskningsdata och administration" - "Försäljning"), ställ in flaggan "Kundorder" och ställ även in alternativet för att använda beställningar som " Beställ från lager och till beställning” (För mer information om alternativ för att använda beställningar, se tilläggsavsnittet).

För att specificera betalningsvillkor för kunder kommer vi i samma avsnitt av programmet att inkludera funktionaliteten för att använda avtal med kunder. Låt oss välja alternativet "Standard och individuella avtal".

För att möjliggöra användningen av "Order till leverantör"-dokumentet måste du aktivera flaggan "Order till leverantörer" i avsnittet "Administration" - "Inköp" (i UT 11.2 är detta "Masterdata och administration" - "Inköp" sektion).

Här kommer vi också att aktivera flaggan "Avtal med leverantörer" för att ange villkoren för köp och betalning med leverantören.

Vi kommer att skapa ett nytt kundavtal som ska användas för att sälja produkter till våra kunder.

Låt oss fylla i betalningsförfarandet enligt villkoren för uppgiften: förskottsbetalning innan beställningen säkras till ett belopp av 10% och 90% - kredit med ett anstånd på 2 dagar.

Nu kommer vi att lägga en ny beställning i programmet från kunden "Ivanov Ivan Ivanovich" (vi kommer att skapa en ny kund i avsnittet "Reglerings- och referensinformation" - "Motparter").

Orderlista:

  • Ekbord 1 st. Pris 10 000 rubel.
  • Skjutgarderob 1 st. Pris 20 000 rubel.

I avsnittet "Reglerings- och referensinformation" kommer vi först att skapa två poster i nomenklaturen.

Låt oss gå till avsnittet "Försäljning" i programmet och skapa ett nytt "Kundorder"-dokument.

Vi kommer att ange de nödvändiga produktartiklarna i kundens dokument.

Vi kommer att ange önskat leveransdatum i beställningen, till exempel 2015-11-06.

I raderna i tabelldelen "Varor" anger vi säkerhetsalternativet (kolumnen "Åtgärder") - "Till säkerhet". När du ställer in denna status kommer programmet automatiskt att ställa in leveransdatum för varorna. Vid beräkning av leveransdatum kommer det önskade leveransdatumet att beaktas.

När du försöker lägga upp ett dokument kommer programmet att visa ett felmeddelande om att betalningsvillkoren har brutits.

Faktum är att i avtalet (som automatiskt upprättades i dokumentet, eftersom detta är det enda avtalet i databasen), angav vi i betalningsvillkoren en förskottsbetalning på 10%.

När du bokför ett dokument i statusen "För slutförande" kontrollerar programmet betalningsvillkoren för dokumentet. Betalningsvillkoren i detta fall har ännu inte uppfyllts.

Vi ställer in orderstatusen till "Under godkännande" och postar dokumentet.

Du kan kontrollera betalningsvillkoren för dokumentet genom att klicka på hyperlänken under tabelldelen av dokumentet.

Som du kan se beräknade programmet automatiskt beloppen och datumen för betalningar (förskott och kredit) för beställningen enligt de villkor som anges i avtalet.

Vid beräkning av betalningsdatum för förskottsstadiet och förskottsbetalning används datum för orderläggning (2015-08-06).

Beräkning av datum för kreditsteg görs från det önskade datumet för leverans av varor, med hänsyn till kalendern som specificerades i avtalet (i vårt fall per kalenderdagar).

Det vill säga att krediten (efter leverans) beräknas som:

Önskat leveransdatum + 2 dagar = 2015-06-13

Vi kommer att behöva dessa uppgifter för att ta hänsyn till planerade betalningar när vi upprättar en betalningskalender.

Vi kommer att göra en betalning från kunden till ett belopp av 3 000 rubel. som ett förskott på en beställning.

Först, i avsnittet ”Reglerings- och referensinformation” – ”Inställningar och referensböcker” – ”Inställning av kassadisk” (i UT 11.2 är detta avsnittet ”Forskningsdata och administration” – ”Information om företaget” – ”Inställning av kassadisk” ”), kommer vi att fylla i information om vårt företags kassaregister.

I avsnittet "Reglerings- och referensinformation" - "Konfiguration av bankkonto" kommer vi också att fylla i information om vårt företags bankkonto (i UT 11.2 är detta avsnittet "NSI och administration" - "Information om företaget" – "Konfiguration av bankkonto").

I dokumentet "Kundorder" klickar du på knappen "Skapa baserat på" - "Kontantbeställning".

Vi kommer att utfärda en kontantorder för ett belopp av 3 000 rubel.

Nu kan vi lägga upp vår kundorder i statusen "För uppfyllande".

Du kan analysera kassabalansen och betalningsschemat med hjälp av rapporten "Betalningsplan" i avsnittet "Ekonomi" (i UT 11.2 är detta avsnittet "Treasury").

Användningen av "Betalningskalender" är tillgänglig när det funktionella alternativet "Begäran om att spendera medel" är aktiverat i avsnittet "Administration" - "Organisationer och fonder" (i UT 11.2 är detta avsnittet "Forskningsdata och administration" - " Treasury”).

Vi kommer att skapa en "Betalningsplan"-rapport.

I rapporten ser vi att den nuvarande kassan är 3 000 RUB.

Den planerade betalningen från kunden är 27 000 rubel.

Det är rätt. Vid beräkning av tillgängligt saldo beaktas planerade betalningar från kunden. I det här fallet presenteras betalningsbeloppet från kunden i rapporten som en rad i enlighet med de betalningssteg som vi angav i kundens beställning.

Rapporten informerar om att på lördag 13.06 kommer kassabehållningen att vara 30 000 rubel.

Nu kommer vi att lägga en "Beställning till leverantören" baserat på vår "Kundorder".

Men först, låt oss skapa en ny leverantör "Möbelservice" i avsnittet "Referensinformation" - "Motparter".

På navigeringspanelen på leverantörskortformuläret, gå till "Avtal med leverantören".

Låt oss skapa ett nytt avtal.

Vi kommer att fylla i all nödvändig information i avtalet.

Vi kommer att ange betalningsvillkoren enligt vår uppgift - kredit (efter leverans) 3 dagar.

Öppna "Kundorder", klicka på knappen "Skapa baserat på" och välj "Beställning till leverantör".

Vi kommer att ange i dokumentet leverantören vi skapade "Möbelservice". Avtalet med leverantören upprättas automatiskt.

Betalningsdatum och belopp kommer automatiskt att beräknas i enlighet med betalningsplanen som vi har definierat i avtalet.

Vi använder inte förskott eller förskottsbetalning på beställningar till leverantören, men vid beräkning av betalningsdatum för förskottsledet och förskottsbetalning används beställningsdatum. Detta tar även hänsyn till önskat leveransdatum för varorna.

Beräkning av datum för kreditsteg görs från det önskade datumet för leverans av varor, med hänsyn till kalendern som specificerades i avtalet (i exemplet under övervägande - med kalenderdagar). I vårt fall är det:

Datum för mottagande (06/09/2015) + 3 dagar = 06/12/2015

Låt oss granska dokumentet.

En ny gruppering för utbetalning av medel till leverantören har dykt upp i rapporten.

Som du kan se, från och med den 12 juni 2015, med hänsyn till det aktuella kassabalansen, kommer vi att få minus 20 000 rubel.

Från och med den 13 juni 2015, med hänsyn till mottagandet av betalning från kunden, bör saldot vara 7 000 rubel.

Det vill säga att det har uppstått en situation att vi vid betalningstillfället till leverantören inte har den summa pengar som krävs.

Låt oss föreställa oss att företagets ledning inledde förhandlingar med banken för att få ett lån. Kontanter från banken till ett belopp av 50 000 RUB. senast 10 juni 2015

I betalningskalendern är det möjligt att registrera planerade kassakvitton med kommandot "Lägg till kvitto".

Ett nytt dokument "Förväntat mottagande av DS" kommer att öppnas framför oss.

Låt oss fylla i det.

Vi kommer att ange en ny DDS-artikel "Annat kvitto på DS" och mängden 50 000 rubel.

Vi kommer att fastställa datumet för dokumentet till 06/10/2015.

Låt oss granska dokumentet.

Vi kommer att generera rapporten "Betalningsplan" igen.

Vi kommer att se att den 10 juni 2015 planeras andra kassakvitton till ett belopp av 50 000 rubel.

Med detta planerade kvitto kommer företaget att ha möjlighet att betala skulden till leverantören.

Med hänsyn till mottagandet av DS från kunden är det totala planerade saldot 57 000 rubel.

Låt oss föreställa oss att ett banklån utfärdades och medel mottogs på vårt bankkonto.

Baserat på dokumentet "Förväntat mottagande av DS", kommer vi att skapa dokumentet "Kvitto av icke-kontant DS".

Vi kommer att ange betalaren "VTB Bank".

Sätt flaggan "Passed by the Bank" och ange datumet då pengarna överfördes av banken.

Låt oss återskapa rapporten "Betalningskalender".

Vi ser att det nuvarande kassabalansen, med hänsyn till mottagandet av ett banklån, redan är 53 000 rubel.

Men raden "Planerat kvitto" försvann inte i rapporten.

Som ett resultat, från och med den 10 juni 2015, är det planerade kassabalansen 103 000 rubel, vilket inte är helt korrekt.

Detta är ett konfigurationsfel i UT11.1.10.153-versionen. Jag tror att utvecklarna kommer att fixa det i framtida utgåvor.

När det gäller vårt ifyllda dokument "Planerade kassakvitton" bör det raderas eller göras opostat.

Dessutom övervägdes inställningarna för betalningsvillkor som tas emot från kunder och överförs till leverantörer, liksom mekanismen för att beräkna betalningsdatum för förskotts- och kreditalternativ.

Funktionaliteten, som vi ser, är enkel och kommer att vara mycket användbar för ekonomichefer och revisorer i företaget för att kontrollera kassabalanser och planera utgifter.

Många 1C-konfigurationer har funktioner som en betalningskalender (PC). Det hjälper dig att utföra kortsiktig kontantplanering (CF) och upptäcka kassaluckor i tid. I 1C:ERP Enterprise Management 2-konfigurationen presenteras PC:n som en bekväm arbetsstation som låter dig skapa dokument, generera rapporter och analysera resultaten. I den här artikeln vill vi uppehålla oss i detalj vid funktionerna i att arbeta med en PC i den nämnda konfigurationen (revision 2.4).

Datorn som helhet är en analytisk rapport som återspeglar inbetalningar, avskrivningar och saldon av finansiella tillgångar, som kan grupperas efter typ - kontanter och icke-kontanter, såväl som efter deras plats - specifika bankkonton eller organisationens kassadisk. Dessutom kan du från betalningskalendern utföra planerade avskrivningar av DS, hantera deras saldon på olika bankkonton och i kassaregistret och flytta dem för att eliminera kassaluckor. Datorn kommer att bli en pålitlig assistent för att hantera kassaflöden även för nybörjare ekonomichefer, förutsatt att rekommendationerna för att arbeta med den beaktas.

Ställa in parametrar för att underhålla en betalningskalender

Arbete med en PC blir möjligt efter att först ha ställt in en viktig programparameter. Låt oss kontrollera det genom gränssnittet "Stamdata och administration/Sätta upp basdata och sektioner/Treasury."

Denna parameter är upprätthålla förfrågningar om att använda medel. PC:n underhålls i 1C:ERP med flaggan inställd Låt oss installera det.


Detta räcker för att komma igång med din PC.

Tillgång till PC är möjlig via gränssnitt "Skassa/Planering och kontroll av medel/Betalningskalender."



Ställa in en betalningskalender i 1C 8.3

Utseendet på PC:n kan anpassas för att passa användarens krav och uppgifter. Som standard öppnas kalendern i två fönsterläge: program/vänster, kalender/höger.


Du kan ändra PC-utgångsläget med knappen "Se", som finns i den övre vänstra delen av kalendern.


Det finns tre lägen totalt för kalendervyn:

  • Ansökningar/Kalender;
  • Kalender/Betalningar;
  • Lista över applikationer.

Det är optimalt att använda det andra läget alla dokument som ger skäl för både att ta emot och spendera DS är tillgängliga i det.


PC:n kan konfigureras för ett specifikt antal planeringsdagar (i föregående skärmdump är det 20 dagar). Ange önskad organisation (i vårt fall är det "Prompostavka"). Ställ in val för ett specifikt bankkonto/kontanter.

Det är mycket viktigt att konfigurera din dator för att kontrollera synligheten för dess linjer. Den är tillgänglig från rullgardinsmenyn för knappar "Mer":


Flera typer av alternativ finns tillgängliga för installation i inställningsfönstret:

  • Visa i kalendern – gör det möjligt att fastställa synligheten för ännu ej godkända utgiftsförfrågningar;
  • Förväntade kvitton – inkluderar synlighet av DS-kvittorader i samband med förlikningsdokument;
  • Förväntade avskrivningar – hanterar synligheten av utgifter utan ansökningar och i samband med förlikningsdokument.

Dessutom kan du i inställningarna välja typ av valuta - förvaltning eller reglerad redovisning. En extra trevlig bonus är möjligheten att ställa in ett planeringsdatum och inaktivera icke-arbetsdagar i kalendern.


Låt oss bekanta oss med strukturen på en PC som motsvarar de tidigare angivna inställningarna.


Till vänster finns en lista över organisationens nuvarande konton, såvida inte ett urval tidigare har gjorts för ett konto. Rapporten innehåller saldon, kvitton, avskrivningar och summor. Rapportkolumnerna gör det möjligt att se förfallna skulder och planerade rörelser per dag. Om du ändrar aktiviteten för kalenderceller, ändras i den nedre tabelldelen listan över dokument som dechiffrerar antingen kvitton, avskrivningar eller belopp för förfallna skulder.

Upprätthålla en betalningskalender i 1C

Som vi nämnde tidigare är PC:n i ERP en arbetsstation, det vill säga att användaren omedelbart kan hantera PC:n på ett öppet sätt.

Planera kassaflöden i betalningskalendern

I kalendern kan du planera förflyttningen av DS, följt av skapandet av nödvändiga dokument inom följande områden:

  • Överföra till ett annat konto;
  • Ge ut till en annan kassadisk;
  • Insamling till banken;
  • Insamling från banken;
  • Valutaväxling.

För att göra detta, välj bara önskad rad från rullgardinsmenyn på knappen


Beroende på vald rad öppnas en dialogruta för att skapa dokument:

  • Order att flytta pengar – för alla rader utom valutaomvandling;
  • Ansökan om utgifter DS - endast för valutaomvandling.

Funktioner för att fylla i betalningsdokument för korrekt underhåll av betalningskalendern

För att systemet entydigt ska klassificera ett visst betalningsdokument som tillhörande en rörelse från ett specifikt bankkonto, är det nödvändigt att i detta dokument ange betalningsformen och ange bankkonto och kassadisk.

Till exempel kommer en kundorder som anger någon form av betalning och inte innehåller namnen på kassaregistret och byteskontot inte att kunna identifieras i PC:n.


En sådan beställning kommer att falla in i de så kallade utestående kvittonen, och raden "Kvitto inte distribuerat" kommer att visas i PC-formuläret. En liknande situation är möjlig med avskrivningen av DS om betalningsdokumenten hos leverantörerna inte innehåller det kassaregister eller löpande konto från vilket betalningar kommer att ske. Sådana belopp återspeglas separat på raden "Avskrivning ej utdelad".


För att förhindra att sådana situationer uppstår måste du noggrant övervaka proceduren för att fylla i detaljerna för betalningsdokument. Det finns inga rader i PC:n med fullständigt ifyllda betalningsdokument "Kvitto inte distribuerat/Avskrivning inte distribuerat."

Spåra och eliminera kassaluckor med hjälp av betalningskalendern i 1C

I processen att underhålla PC kan en organisation uppleva kassaluckor, d.v.s. en tillfällig brist på medel eller ett överskott av tillgängliga och inkommande medel över betalningar som behöver göras av organisationen under samma tidsperiod, vanligtvis samma dag. I PC:n återspeglas kassagap mycket tydligt som negativa saldobelopp på ett visst bankkonto eller kassaregister i en organisation:


Genom att analysera din dators tillstånd för förekomsten av kassaluckor kan du snabbt svara på deras förekomst. Det finns flera sätt att eliminera kassagapet:

  • Flytta pengar från ett bankkonto till ett annat för att säkerställa tillräckligt med saldo;
  • Ändra beloppet för DS-avskrivning, minska det och skjuta upp betalningar till datumet för planerade kvitton;
  • Säkerställ tillräcklig tillgång på DS från kunder.

Låt oss ta ett exempel på hur man flyttar pengar mellan konton. Som du kan se i skärmdumpen ovan har ett kassagap bildats på kontot "7231/Prompostavka (RUB)/Eget konto". Om vi ​​analyserar datorn som helhet för organisationen kommer vi att se att det finns ett annat bankkonto med en tillräcklig mängd medel.


Vi kommer att kunna flytta DS från ett konto till ett annat, enligt beskrivningen ovan, genom att skapa ett dokument


Efter detta kommer vi att uppdatera PC:n och se till att kassagapet har försvunnit.


Ansökningar om utgifter i 1C-betalningskalendern

Bokföringssystemet "1C:ERP 2" låter dig spendera DS både med och utan obligatorisk användning av applikationer på ett visst bankkonto i organisationen. Vi kan hantera ansökningar via ett specifikt bankkonto för organisationen.



Vi kommer att skriva av DS från ett bankkonto utan obligatoriska ansökningar. För att göra detta på en PC, använd knappen


I det här fallet kommer ett dokument att genereras "Avskrivning av icke-kontanta medel" längs vilken DS faktiskt kommer att flyttas.

Vid obligatorisk användning av utläggsförfrågningar baserade på leverantörsbeställningar och andra kvittodokument som väntar på betalning, måste du skapa dessa förfrågningar, som kommer in i PC:n.


I en PC kan du snabbt hantera applikationer, flytta dem efter betalningsdatum, dela upp betalningar och därmed också hantera kassaluckor.


För att underlätta arbetet med ett stort antal applikationer tillhandahåller PC:n grupperingar av applikationer enligt olika kriterier:


Detta avslutar beskrivningen av betalningskalenderns funktioner i 1C:ERP 2. Vi hoppas att du med hjälp av våra instruktioner snabbt kommer att bemästra arbetet med en PC och börja hantera din organisations medel med detta verktyg.