Operasyonel nakit akışı planlaması veya nakit akışı kontrol sisteminin nasıl oluşturulacağı. Fon harcamak için alt sistem "elektronik uygulamalar" Fon harcamak için başvuru 1c up

1. Giriş

Nakit planlaması, finansal muhasebenin aksine yönetim muhasebesinin ana görevlerinden biridir.

Elbette yönetim ve muhasebe arasında başka önemli farklılıklar da vardır (analitik için farklı gereksinimler, varlıkların/yükümlülüklerin değerlendirilmesi ve yeniden değerlenmesi için farklı gereksinimler, rezerv oluşturma ihtiyacı vb.), ancak planlama sorunlarını çözme ihtiyacı en zor olanıdır. onlara.
Planlamanın karmaşıklığı sadece planın hazırlanmasında (hesaplanması, farklı senaryolara göre oluşturulması) değil, aynı zamanda gerekli olmasında da yatmaktadır:

Yeniden planlama gerçekleştirin;
Planları güncelleyin, ayarlamaları sonraki dönemlere aktarın;
Bir plan yapın - gerçeklere dayalı bir analiz.

Çoğu işletmede (otomasyon için 1C kullanılarak) programda planlama yapılmadığı kabul edilmelidir.
"Muhasebeyi kurmalıyız..." - birçok kişi bunu savunuyor.

Muhasebenin iyileştirilmesi gerekiyor evet, ancak planlama pahasına değil.
Elbette hala planlama yapıyorlar (ancak 1C'de değil, XLS'de). Ve ilk, asıl görev (çözmeye çalıştıkları) nakit planlamasıdır.

(1) Stratejik (bütçeleme);
(2) Operasyonel.

Ve eğer bütçeleme (elbette planlamada yukarıdan aşağıya bir yaklaşımla) XLS kullanılarak yapılabiliyorsa, o zaman operasyonel planlama yapılamaz.
Sonuç olarak, çoğu zaman minimum sayıda kullanıcı (1-2 kişi) bütçe tablolarıyla çalışır. Çoğu işletme için bütçeleme kalemlerinin ve diğer analizlerin sayısı çok fazla değildir. Yani XLS'de her şey manuel olarak işlenebilir.

Ancak d/s'nin operasyonel planlamasına gelince, burada durum farklı. Yani, genellikle ödenmesi gereken çok sayıda fatura, çok sayıda düzenli ödeme, müşteri siparişleri için beklenen ödemeler vb. vardır.

Ayrıca tüm bunlar, programın çeşitli kullanıcılarının çalıştığı, belgelerin ayarlandığı, durumun değiştiği vb. çok sayıda birincil belgeye "bağlanabilir".

Operasyonel planlama ile bütçeleme arasındaki bir diğer önemli fark, bunun genellikle aşağıdan yukarıya doğru gelmesidir. Yani, her zaman departman çalışanları tarafından doldurulan "D/s giderleri talepleri"nden.

Dolayısıyla bu başvuruların zamanında işleme alınması, kabul edilmesi/reddedilmesi, "planlanması" ve ödemelerinin yapılması gerekir.

Toplam: d/s için operasyonel planlama ilk planlama görevi, herhangi bir işletme için 1C'de otomatikleştirilmesi gerekir.

Ve planlama sonucunda finans departmanı / hazinenin sistemde şunları “görmesi” gerekir:

Ne zaman, kime, hangi banka hesabından/nakitten, ne kadar ödeme yapılması gerektiği;
Cari bakiyeler, planlanan giderler ve nakit makbuzları dikkate alarak “falanca” tarihteki nakit bakiyesi ne olacak? Sözde kaçınılmalıdır. "nakit açığı"
Yani ödeme takvimi ile çalışmaya ihtiyaç var.
Karşı taraflarla olan borç ne olacak belirtilen tarihler Planlanan ödemeler, makbuzlar ve mevcut karşılıklı ödeme dengesi dikkate alınarak.
Yani hesaplama takvimi ile çalışmaya ihtiyaç var.

Bu makalenin amacı – d/c için operasyonel planlamayı otomatikleştirmenin olanakları hakkında konuşun. Aynı zamanda, 3 farklı sirkülasyon konfigürasyonunun karşılaştırmalı bir analizi gerçekleştirilecektir (ikisi 1C'den standart, biri isewiseadvice firmasından uzmanlaşmıştır).

Yapılandırmaların her biri operasyonel planlama sorunlarını çözmek için kullanılabilir ancak projenizin kapsamına ve ölçeğine göre dengeli bir seçim yapılmalıdır.

2. Kontrollü başlatıcının özellikleri 1.3

Şu anda 1C, UPP'nin uzun zamandır beklenen yeni baskısını (revizyon 2) henüz yayınlamadı. Bu nedenle, SCP 1.3'ün ilgili alt sistemleri olan mevcut olanlara odaklanacağız:

“Nakit Harcama Talepleri” alt sisteminin konfigürasyonda nispeten yakın zamanda (2011) güncellendiğini belirtmek gerekir. Sonuç olarak, yönetilen arayüz modunda bölüm panelinde "d/s/ harcama istekleri" öğesi belirdi.

Standart bir konfigürasyonda, dosya modunda "D/s Giderleri Talebi" (diğer adıyla ZRDS) belge formunu açmayı denerseniz, "Şununla Çalışmak" genel modülünden "Küresel Değerler" değişkeni için hemen bir hata görünür. Genel Değişkenler”.

Ancak bu tür hatalar, dedikleri gibi düzeltilebilir: "tortu kalır." Yani UPP ZRDS alt sisteminde yeterince "pürüzlülük" var.
Bir WEB tarayıcısı aracılığıyla bir ZRDS belgesi oluşturma yeteneği faydalıdır, ancak pratikte belgenin standart formunun basitleştirilmesi ve ergonomisi hakkında dikkatlice düşünmeniz gerekecektir. Bu özellikle mobil cihazlar için önemli olacaktır.

Ancak ödeme takvimine gelince, ince istemci modunda, bir WEB tarayıcısı vb. aracılığıyla uzaktan. onu kullanamayacaksın. Bunun nedeni, Nakit Yönetimi alt sisteminin uzun süredir güncellenmemesi ve özellikle Ödeme Takvimi raporunun bir veri kompozisyon sistemi üzerine kurulmamış olmasıdır. Bu nedenle bu rapor ince istemcilerde kullanılamaz, özel ayarlar oluşturulma olanağı yoktur.

ZRDS ile çalışırken uygulamaların koordinasyonu ve onaylanmasına ilişkin düzenlemeler önemli bir yer tutmaktadır. Bağlı olarak örgütsel yapı kurumsal ve diğer iş özellikleri nedeniyle, başvuruları onaylamaya yönelik dahili prosedür (onay düzenlemeleri) oldukça karmaşık olabilir (çok aşamalı, değişken vb.). Dolayısıyla bu otomasyon açısından kolay bir iş değil.

KPP'de koordinasyon ve onay alt sistemi uygulanmaktadır. Oldukça esnek ayarlar sağlar.

Onay, başvuru için ödeme yapılması gerektiğinin teyididir. Tipik olarak onayın departman başkanlarından, yöneticilerden ve şirketin diğer sorumlu kişilerinden geçmesi gerekir.
Onay, başvurunun ödeneceğine dair nihai onaydır (Sayman tarafından). Bu durumda ödeme tarihi ve ödemenin yapılacağı banka hesabı/kasanın belirlenmesi gerekmektedir. Böylece ödeme operasyonel plana (ödeme takvimi) düşer.

Kontrollü başlatıcının standart işlevselliğinin bazı yönlerinin, alt sistemin fiili uygulaması için gerekli olanı sağlamadığına dikkat edilmelidir.
Bu “anları” daha sonra yazacağım ama şimdilik tipik bir konfigürasyonun hangi işlevleri sağladığına bakalım.

Başvuru onay mekanizmasının kullanımını her kuruluş için ayrı ayrı etkinleştirebilirsiniz.

Uygulamanın sırasını rotalar ve rota hiyerarşisi aracılığıyla yapılandırmak mümkündür.

Uygulama yönlendirme mekanizmalarında departman dizinindeki hiyerarşinin dikkate alınmadığını belirtmek gerekir.
Koordinasyon ve onayın teknik olarak bir iş süreci mekanizması kullanılmadan oluşturulduğunun da iptal edilmesi gerekiyor.

Her noktada, uygulamanın onayının alınacağı bir/birkaç kullanıcıyı belirleyebilirsiniz. Yani başvuru bunlardan herhangi biri (bunu ilk önce yapmayı başaran kişi) tarafından onaylanabilir.

Her departman için karşılık gelen bir onay rota noktası atayabilirsiniz. Bunun özü şudur: Bir başvuru formunu (ZRDS) doldururken, Merkezi Federal Bölge (bölüm) belirtilmelidir. Ve belirtilen bölüme bağlı olarak, UPP ilgili onay noktasını “bulur” ve başvuruyu onay için bu noktaya “gönderir”.

Onay rotasını ayarlarken departman belirtmemek de mümkündür. Bu durumda böyle bir koordinasyon noktası, karşılık gelen rota noktasının özel olarak belirtilmediği tüm CFD'lere "uygulanacaktır".

Onayın kendisi özel bir "Başvuru onayı" işlemi kullanılarak gerçekleştirilir.

Planlanan fon kullanılabilirliğinin analizi, ödeme planı ve nakit açıklarının takibi “Ödeme Takvimi” raporunda gerçekleştirilir.

Planlanan d/s (ZRDS) tüketimine ek olarak, planlanan d/s alımını da dikkate alabilirsiniz. Bu amaçlar için özel bir “Planlanan gelir makbuzu” belgesinin hazırlanması öngörülmektedir.

"Planlı d/c alımı" belgesinde durumlar (hazırlandı, üzerinde anlaşmaya varıldı, vb.) bulunmasına rağmen, bu belgeyi (ZRDS'nin yanı sıra) koordine etme fırsatının bulunmadığına dikkat edilmelidir. Yani, belge durumlarını değiştirmek yalnızca “ Manuel kontrol».

Ve UPP'de, "Planlı nakit girişi" belgelerini hazırlamadan, alıcılardan planlanan nakit girişini dikkate almak mümkündür.

Yani, bir alıcı için “Müşteri Siparişleri” veriliyorsa, bu planlı makbuz ayrı bir “Siparişleri dikkate alan ödeme takvimi” raporunda görülebilir.

Ödeme Takvimi raporunun yanı sıra Nakit Kullanılabilirliği Analizi raporu da bulunmaktadır.

Aynı zamanda d/s rezerve etmek (gider başvurularına göre) veya planlanan gelirlere karşı başvuru yapmak da mümkündür.

Ayrıca ZRDS'yi kapatma ve d/c'den planlanan geliri kapatma işlevi de mevcuttur. Bu amaçlar için “normal müşteri” modunda “Harcamalar/makbuzların kapatılması başvuruları” belgeleri sağlanır.

Ancak bu işlevsellik, ince/web istemcisi modunda da desteklenmez.
Burada "kesin rezervasyon" tekniğinin belge girişi kronolojisine güçlü bir şekilde bağlı olduğunu ve bunun ayarlamaları ve yeniden planlamayı zorlaştırdığını anlamalısınız.

Bu nedenle, işlevsellik UPP'de daha ziyade "geçmişin mirası" olarak bırakılmıştır ve d/s'nin kullanılabilirliğini analiz etmek için ödeme takvimi kullanılmalıdır.

Dolayısıyla kontrollü başlatıcının işlevselliğini değerlendirdik ve şimdi standart konfigürasyonun pratikte projelerde değiştirilmesi gereken yönlerini listeleyeceğim:

“D/s harcaması başvurusu” belgesine göre:
1. Belgede “Bölüm”ü belirtebilirsiniz (bu arada, konfigürasyonda Merkezi Federal Bölge - mali sorumluluk merkezi olarak belirlenmiştir). Ancak bir başvurunun bir bölümden (CFD) gönderilmesi oldukça mümkündür ve bu durumda maliyetlerin ayrıca başka bir bölüme/bölümlere (CFD - finansal yönetim merkezleri) atfedilmesi/dağıtılması gerekecektir.
  Dijital işlevleri vb. belirtme yeteneği. - mevcut olmayan.
  Rotayı değiştirme veya uygulamayı başka rotalara yönlendirme olanağı yoktur.

Cari hesaplar arasında, hesaptan kasaya vb. nakit transferinin planlanması mümkün değildir.

Anlaşma süreci:
1. ZRDS'yi koordine etmek mümkündür ancak planlanan d/s alımını koordine etme imkanı yoktur.
2. Uygulamada diğer çalışanların onaylarının alınması zorunlu hale geliyor. Aynı zamanda sistemin “onayı kimin, kim için yaptığı” bilgisini de kaydetmesi gerekiyor.
  Bir koordinasyon noktasında birden fazla olası uygulayıcının kurulması seçeneği çoğu zaman uygun değildir, dolayısıyla bu uygulayıcı diğer koordinasyon aşamalarında belirtilebilir. Sonuç olarak tüm bunlar, onay talepleri listesinde çalışanın aynı anda hem ana hem de dolaylı onay görevlerine sahip olmasına yol açacaktır. Elbette bu kullanıcının kafasını karıştırır ve kullanışlı değildir.
  Özetlemek gerekirse, başka bir icracı için koordinasyon yapma yeteneği, kimin kimin için koordinasyon yapma hakkına sahip olduğunu belirtme yeteneği yoktur.
3. Başvuruların onaylanması sürecinde, bir başvuru yol boyunca bir sonrakine onay için iletildiğinde, bir sonraki uygulayıcıyı ve başvurunun yazarını otomatik olarak bilgilendirme (e-posta yoluyla) işlevi talep görmektedir. .
4. Uygulamanın yazarı halihazırda koordinasyondan/onaydan sorumluysa (rotanın herhangi bir aşamasında!), o zaman programın rotayı otomatik olarak "kısaltması" ve uygulamayı mümkün olan en yüksek seviyeye yönlendirmesi oldukça mantıklıdır. Ancak KPP'de bu öngörülmemiştir.
- Yukarıdaki gereksinimlerin tümü, standart konfigürasyona dahil olmasa da yine de .

Raporlar, erişim hakları.
1. Uygulamalara erişimin yalnızca mevcut yazarlar/sanatçılar (koordinatörler) tarafından sınırlandırılması olasılığına yönelik bir talep bulunmaktadır; Kullanıcının kullanabileceği departmanlara göre.
2. Fiili ve planlanan borcun kontrolüne (günlere ve aralıklara göre) ilişkin herhangi bir raporlama bulunmamaktadır. Bu hem alıcılar hem de tedarikçiler için geçerlidir.
3. Raporlama ve bazı işlevler ince/web istemcisi modunda çalışmaya uygun değildir.
Düzenli anlaşmalar ve sözleşmelerin muhasebeleştirilmesi.
1. Tedarikçilere düzenli olarak ödeme yapmanın gerekli olduğu durumlar sıklıkla vardır. Örneğin kira ödemeleri vb.
  UPP bunu otomatik olarak ödeme takvimine vb. yansıtmaz. bu yaklaşan masraflar. Yani bu tür ödemeleri manuel olarak takip etmek ve ödeme taleplerini doldurmak zahmetli ve emek yoğun bir işlemdir.
2. Alıcılar ve tedarikçilerle yapılan anlaşmalar, peşin ödeme yüzdesi, ödeme koşulları vb. için koşullar öngörebilir.
  UPP tüm bu bilgileri otomatik olarak kaydetmez ve (sonuç olarak) bunları ödeme takvimine otomatik olarak yansıtır.

3. UT 11.1'in Özellikleri

Yeni konfigürasyon "Ticaret Yönetimi Rev.11"in piyasaya sürülmesiyle birlikte, operasyonel planlama ve mali kontrol görevleri için birçok yeni, kullanışlı özellik ortaya çıktı.
UT11'in bu bölümündeki belki de en önemli şey (UPP 1.3 ile karşılaştırıldığında) ödeme planının muhasebeleştirilmesi mekanizmasıdır. Bu mekanizma, büyük ölçüde eksik olan şeyi, yani düzenli anlaşmalar ve sözleşmeler kapsamında planlama/muhasebe otomasyonunu "kapatır".

Böylece UT11'de harcamaları ve makbuzları planlamak için (tabii ki gerek yoksa) belge hazırlamanıza gerek kalmayacak ve aynı zamanda ödeme takvimi normal şekilde oluşacaktır.

“Ödeme takvimi” raporunun “standart ayarlarının” beklentileri tam olarak karşılamadığını iptal edebilirsiniz (bu nedenle takvim görüntülenmez), ancak kullanıcı modunda “ödeme tarihine” ve rapora göre gruplandırma ekleyebilirsiniz. olağan biçimde oluşturulacaktır.

Raporun işlevselliği, veri kompozisyon sisteminin kullanılması nedeniyle (SCP 1.3'e kıyasla) büyük ölçüde genişledi. Artık rapor bir ince/web istemcisinde oluşturulabilir, veritabanına kaydedilebilir ve farklı kullanıcılara ihtiyaç duydukları ayarlar atanabilir.

UT11, ev eşyalarının tüketimini ve alımını planlamanın yanı sıra artık ev eşyalarının hareketini planlama işlevine de sahip. Bu amaçlar için “Hanelerin yer değiştirme emri” belgelerini hazırlayabilirsiniz.

“Nakit harcama başvurusu” belgesine ilişkin UPP 1.3 ile karşılaştırıldığında, dikkate alınan ticari işlem türlerinin sayısı artmıştır:

Artık hem “Fon harcama başvurusu” belgelerini hem de diğer siparişleri onaylamak mümkün:

Borçları aralıklara/son teslim tarihlerine göre analiz etmek için “Alacak Hesapları” raporu sağlanır. Gerekirse borç takvimi de oluşturabilirsiniz. Bunu yapmak için özel modda ödeme tarihlerine göre bir gruplandırma eklemelisiniz.

Maalesef UT11 (daha önce olduğu gibi) tedarikçilere göre borç takvimini analiz etme olanağı sunmuyor. Ancak bu görev için UT11'in sonuçlandırılması gerekiyor.

Özetlemek: yeni metodolojik çözümler "1C", 8.2 platformunun yetenekleriyle birlikte, operasyonel planlama ve d/c kontrolü görevlerinin otomatikleştirilmesi için iyi bir temel sağlar.

Ancak aynı zamanda UT11 konfigürasyonunun hazine otomasyonu ve finansal planlama için eksiksiz, hazır bir çözüm olmadığını da anlamalısınız.

İlk olarak UT11, harcama taleplerini ve diğer d/c planlama belgelerini koordine etmek/onaylamak için çok basitleştirilmiş bir biçimde bir mekanizma uygular. Yani yönlendirme mekanizmaları yoktur, başvuruları onaylama süreci sadece durum belirlemeye indirgenmiştir.
İkincisi, UT11'in bütçeleme alt sistemi yoktur ve (sonuç olarak) planlanan bütçelere yönelik başvuruları izlemeye yönelik bir işlevsellik yoktur.

4. WA Özellikleri: Finansör

Geçmişte WA:Financier konfigürasyonu Hazine Yönetimi ürünü temel alınarak geliştirildi.

Aynı zamanda WiseAdvice'ın yeni "Finansçı" çözümü şunları da içeriyor:

Bütçe planlama alt sistemi;
Sözleşme yönetimi alt sistemi;
Fiili ödemelerin oluşturulması ve muhasebeleştirilmesi için alt sistem;
Şablonlara dayalı belgeler oluşturmak/doldurmak için esnek, özelleştirilebilir mekanizma;
Esnek, özelleştirilebilir müşteri-banka entegrasyon alt sistemi.

"WA: Finansçı" nın hazine açısından ana işlevini ele alalım - sözleşme şartlarını dikkate almaktan ödeme takvimi oluşturmaya kadar.

Başvuru onay süreci sırasında, yalnızca belgeyi onaylamak/reddetmekle kalmaz (UPP'de yapıldığı gibi), aynı zamanda başka işlevler de mevcuttur: örneğin, bir belgeyi revizyon için göndermek veya ek bilgi talep etmek. bilgi.
Tüm bu süreç otomatik hale getirilmekte ve buna bağlı olarak belge onay işlemlerinin durumu hakkında raporlama sağlanmaktadır.

5. Sonuçlar

Sonuçlar:

Mali departmanların, hazinelerin, karmaşık organizasyon yapılarına sahip kuruluşların çalışmalarını otomatikleştirmek. yapı en uygun çözümdür "WA: Finansör".
Bu çözüm uzun süredir gelişiyor ve gelişiyor, buna göre farklı finansal kurumların özellikleri ve gereksinimleri birikiyor. departmanlar ve hazineler. Çözümü geliştirmek için gereken toplam işçilik maliyeti 5.000 kişi/saatin üzerindeydi.
WA: Financier çözümünün avantajı, gelişmiş işlevselliği ve çok sayıda program ayar mekanizmasıdır. Böylece, bu çözümün kısa sürede ("kullanıma hazır uygulama" olarak adlandırılan) uygulanması, ek gerekmeden mümkündür. geliştirme, programlama vb.
Çözüm, tüm ana standart konfigürasyonlarla iki yönlü değişim mekanizmalarını içerdiğinden, mevcut yapıya entegrasyon (UT, UPP, Kompleksnaya, Bukh veritabanları ile veri alışverişi) zor olmayacaktır.
Finans departmanını/hazineyi otomatikleştirmek kapsamlı bir otomasyon projesinin parçası olarak en iyi çözüm UPP'ye dayalı.
Aynı zamanda kontrollü başlatıcının işlevselliğinin iyileştirmeler gerektireceğini anlamalısınız.
Özellikler, mali gereksinimler. departmanlar ve hazineler UPP'ye ayrı, özel çözümlerde olduğu kadar derinlemesine yerleştirilmemiştir.
Dolayısıyla bu görevler için SCP'nin uygulanması yalnızca bir otomasyon projesinin parçası olarak gerçekleştirilmelidir.
İçin büyük organizasyonlar hazine departmanının otomasyonu için UT11 uymuyor.
Bu kararda öncelikle planlama dokümanlarının koordinasyonu/onaylanması için herhangi bir mekanizma bulunmamaktadır.
İkincisi, bütçeleme alt sistemi yoktur ve operasyonel planlama sırasında bütçelerin uygulanması üzerinde kontrol yoktur.
Ancak UT11 için mükemmel otomasyon (operasyonel planlama d/c dahil) küçük mali şirket departmanları.

“Fon harcama talebi” belgesi, ödemelerin planlanması ve koordinasyonu için tasarlanmıştır.
“DS harcama talebi” belgesi “Hazine” - “Fonların planlanması ve kontrolü” - “DS harcama talepleri” - Oluştur bölümüne giderek oluşturulabilir.
“DS harcama talebi” belgesi, oluşturma sırasında seçilen çeşitli işlem türlerine sahiptir. Her uygulama türü, her biri bu talimatta açıklanacak olan çeşitli ticari işlemleri yansıtmayı amaçlamaktadır.
Oluşturulan "DS harcama başvurusu" belgeleri "Ödeme Kaydı" belgesi kullanılarak toplanır ve üzerinde anlaşmaya varılır. Başvuruların onaylanmasının ardından, banka tarafından ödeme yapılmak üzere müşteri bankasına yüklenen “Nakit dışı DS'nin silinmesi” belgeleri otomatik olarak oluşturulur.
Aşağıda her bir operasyon türü için “DS harcamalarına ilişkin başvuru” belgelerinin yürütülmesine ilişkin örnekler yer almaktadır.

Tedarikçiye ödeme
Bir tedarikçiye yapılan ödeme işlemlerini işlemek için, "DS harcama talebi" belgesinin işlem türü amaçlanmaktadır - "Tedarikçiye ödeme".
Yeni “DS harcama başvurusu” belgesinde, belgenin işlenmesi için doldurulması gereken alanlar kırmızıyla işaretlenmiştir. Belge “Onaylanmadı” durumunda oluşturulur, ödeme kaydının onaylanması sırasında durum otomatik olarak değişir. Uygulamanın oluşturulma sırasındaki önceliği otomatik olarak “Orta” olarak ayarlanır.

Şekil 1. “DS harcama başvurusu” belge formu, işlem türü “Tedarikçiye ödeme” (doldurulmamış)
“DS harcama başvurusu” belgesinin ayrıntıları aşağıdaki şekilde doldurulmalıdır:
Temel sekme
Sayı– yürütme sırasında otomatik olarak oluşturulur, manuel olarak ayarlanamaz.
tarih– oluşturulduğunda geçerli tarih ayarlanır.
Organizasyon– düğmesini kullanarak önerilen kuruluşlar listesinden seçim yapmalısınız veya alana adı girerek gerekli değer seçim için sunulacaktır.
Alt bölüm– “Kurumsal Yapı” dizininden ödemenin gerçekleşeceği bölümü seçmelisiniz.
Başvuru sahibi– varsayılan olarak uygulamayı oluşturan mevcut sistem kullanıcısı belirtilir.
Planlama– varsayılan ayar “Ödeme para biriminde”dir ve değiştirilemez.
Toplam– gerekli ödeme tutarını gösterir.
Para birimi– gerekli ödemenin para birimini belirtin.
Operasyon– oluşturma sırasında seçilen “DS harcama başvurusu” belgesinin işlem türü yansıtılır
ödeme tarihi– tedarikçiye ödemenin planlanması gereken tarihi belirtir.
Ödeme şekli– varsayılan ayar “Herhangi bir biçimde”dir ve değiştirilemez.
Alıcı– “Karşı Taraflar” dizininden ödeme yapılması gereken tedarikçiyi belirtir.
Alıcının hesabı– “Alıcı” seçildiğinde, alıcının hesabı otomatik olarak ayarlanır; gerekirse tedarikçi tarafından sağlanan “Ödeme Faturası”nda farklı bir hesap belirtiliyorsa, “Banka Hesapları” dizininden gerekli hesabı seçmelisiniz.
Sınırın üzerinde– sistem, sırasıyla şubeler ve nakit akışı kalemleri bağlamında nakit harcamalarını sınırlamak için bir sistem sürdürüyorsa, yapılan ödeme tutarı daha önce limite dahil edilmemişse, belgeyi gönderirken kullanıcı bir hata mesajı alacaktır. ve başvuru işleme alınmayacaktır.

Şekil 2. Limiti planlanmayan bir sipariş verilirken oluşan hata örneği.
Limitin üzerinde emir vermek için “Limit Aşımı” bayrağını ayarlamanız gerekir.
Bütçeye aktarım– ödeme bütçeye transfer ise bu bayrak ayarlanır. Bayrağın ayarlanması, bütçeye yapılan ödemeler için gerekli olan KBK, OKTMO vb. değerlerini girmenize olanak sağlar.

Şekil 3. “Bütçeye aktar” bayrağının ayarlanması örneği.
UIP– yalnızca alacaklıyla yapılan sözleşmede belirtilmesi durumunda belirtilen benzersiz bir ödeme tanımlayıcı.
Ödemenin amacı- program, "Ekle" düğmesini kullanarak ödeme amacının otomatik olarak doldurulması için çeşitli seçenekler sunar.

Şekil 4. "Ödeme amacı" alanını otomatik doldurma seçenekleri.
Belgelerin listesi dahil. KDV- “ödeme şifre çözme” sekmesinden ödeme nesneleri hakkında bilgi görüntülenecektir

KDV dahil (%18) (tüm tutar için), dahil KDV (%10) (tutarın tamamı için), Vergi hariç (KDV)- KDV bilgisi girilen metne eklenecektir.

Alıcının banka hesabından metin- karşı tarafın hesap kartından "Ödeme amacı metni" alanına belirtilen metni ekler.

Şekil 5. “Temel” sekmesinin doldurulmasına örnek.

Ödeme Ayrıntıları sekmesi
“Ödeme Kod Çözme” sekmesi, ödeme ve alacaklıyla yapılan karşılıklı ödemeler hakkında ayrıntılı bilgi sağlar.
Ödeme bir liste olarak girilebilir, yani. birden fazla hesaplama nesnesine dağıtmak veya bölmeden yalnızca bir hesaplama nesnesini seçmek mümkündür.
Devlet savunma fonlarından ödeme– bayrak yalnızca ödemenin savunma hükümetinin emri çerçevesinde yapılması durumunda konulur, diğer durumlarda bayrak konulmaz.
Hesaplama nesnesi– ödeme nesnesi olarak “Karşı tarafla anlaşma”yı (başvuru belgesinin bu tür işlemi için seçildiğinde, “Tedarikçi/icracı ile” ilişki türüyle anlaşmalar mevcuttur) veya mutabakata varılan “Sipariş” belgesini belirleyebilirsiniz. tedarikçiye”.
Sağlayıcı
Karşılıklı yerleşim miktarı– bir belge gönderilirken otomatik olarak ayarlanır.
Para birimi– bir hesaplama nesnesi seçildiğinde otomatik olarak ayarlanır.
DDS makalesi– ödeme türüne karşılık gelen nakit akışı kalemini belirtin.
Bir yorum– gerekirse, ödeme şifresinin çözülmesiyle ilgili bir yorum belirtin.

Şekil 6. "Ödeme Kod Çözme" sekmesinin doldurulmasına örnek.
Hesap dağıtımı sekmesi
“Hesaplara Dağıtım” sekmesinde, fonların borçlandırılması gereken kuruluşun banka hesabı belirtilir. Ödeme tutarı ve tarihi “Temel” sekmesinde belirtilen verilere göre otomatik olarak ayarlanır.

Şekil 7. “Hesaplara Göre Dağıtım” sekmesinin doldurulmasına örnek.

Şekil 8. "Tedarikçiye ödeme" işlem türüne sahip bir uygulama için otomatik olarak oluşturulan "Nakit dışı DS'nin silinmesi" belgesine bir örnek.

Ödemenin müşteriye iadesi
Müşterilere iade işlemlerini gerçekleştirmek için, "DS harcama başvurusu" belgesindeki işlem türü amaçlanmaktadır - "Müşteriye ödeme iadesi".
Bu tür bir işlemle "DS Harcama Başvurusu" belgesinin ayrıntılarının bileşimi, tedarikçiye ödeme yaparken ayrıntıların bileşimi ile aynıdır, tek fark karşı tarafın türü ve ödeme nesnesidir.

Şekil 9. “DS harcama başvurusu” belgesinin formu, işlem türü “Müşteriye ödeme iadesi”
Alıcı– “Karşı Taraflar” dizininden ödeme yapması gereken müşteriyi belirtir.
Hesaplama nesnesi– ödeme nesnesi olarak “Karşı tarafla anlaşma” (başvuru belgesinin bu tür işlemi için, seçim yaparken “alıcı/müşteri ile” ilişki türüne ilişkin anlaşmalar mevcuttur) veya mutabakata varılan belgeyi belirtebilirsiniz. Müşteri siparişi".
Alıcı– bir hesaplama nesnesi seçildiğinde alan otomatik olarak doldurulur. Hesaplama nesnesinin ilgili alanında belirtilen "Ortaklar" dizin öğesi yüklenir.

Şekil 10. "Ödeme Kod Çözme" sekmesinin doldurulmasına örnek.
Onayın tüm aşamalarını geçtikten sonra, "DS harcama başvurusu" belgesine "Ödeme için" durumu atanacak ve "Nakit dışı DS'nin silinmesi" belgesi otomatik olarak oluşturulacaktır.

Şekil 11. "Müşteriye ödeme iadesi" işlem türüne sahip bir uygulamaya dayalı olarak otomatik olarak oluşturulan "Nakit dışı DS'nin silinmesi" belgesine bir örnek.

Sorumluya verilmesi
Sorumlu bir kişinin banka hesabına fon sağlanmasına yönelik işlemleri resmileştirmek için, “DS harcama başvurusu” - “Sorumlu kişiye ihraç” belgesinin işlem türü amaçlanmaktadır.

Şekil 12. “DS harcama başvurusu” belgesinin şekli, işlem türü “Sorumluya verilmesi”
Sorumlu kişi– çalışan “rehberinden belirtilir” Bireyler”Parayı transfer etmenin gerekli olduğu kişi.
Rapor- önerilen dönemler listesinden, muhasebecinin alınan tutar hakkında rapor vermesi gereken süreyi belirtmek gerekir.

Şekil 13. "Ödeme Kod Çözme" sekmesinin doldurulmasına örnek.
Onayın tüm aşamalarını geçtikten sonra, "DS harcama başvurusu" belgesine "Ödeme için" durumu atanacak ve "Nakit dışı DS'nin silinmesi" belgesi otomatik olarak oluşturulacaktır.

Şekil 14. "Sorumluya ihraç" işlem türüne sahip bir uygulamaya dayalı olarak otomatik olarak oluşturulan "Nakit dışı DS'nin silinmesi" belgesine bir örnek.

Bir işletmenin modern rekabet ortamında etkili bir şekilde var olabilmesinin temel koşulu, etkili bir yönetim mekanizmasının oluşturulmasıdır. nakit akışları hızlı ve güvenilir bilgi üretiminin sağlanması, karşılıklı mutabakatların düzenlenmesi, ödeme disiplininin artırılması ve sonuçta nakit cirosunun hızlandırılmasıdır.

Yapılandırma, iki ana işlevi yerine getiren otomatik kurumsal nakit yönetimine yönelik araçlar içerir:

işletmenin fonlarının takas hesapları ve kasalar üzerindeki fiili hareketinin operasyonel muhasebesi;
İşletmenin nakit giriş ve giderlerinin operasyonel planlaması.

Bir işletmenin harcamalarının ve fonlarının alınmasının genel planlaması bütçeleme çerçevesinde gerçekleştirilir. Hazırlanmakta olan mali plan - bütçe - nakit yönetimi alt sistemi için bir dizi kural ve kısıtlama görevi görür.

Ancak nakit yönetimi işlevselliği çerçevesinde, operasyonel bir mali plan - bir ödeme takvimi - korunur. Birkaç gün önceden ödeme takvimi oluşturmak mantıklıdır.

Ödeme takvimi, harcama talepleri ve planlanan nakit makbuzlarının bir koleksiyonudur. Ödeme takvimi, fonların depolandığı yerlere (banka hesapları ve işletmenin kasaları) kadar ayrıntılarla derlenir. Bir ödeme takvimi derlerken fizibilitesi otomatik olarak kontrol edilir - depolandıkları yerlerdeki nakit rezervlerinin yeterliliği.

Finansal planlama fonksiyonunun iki konfigürasyon alt sistemine (bütçeleme alt sistemi ve nakit yönetimi alt sistemi) bölünmesi, finansal yönetim fonksiyonlarının işletmenin çeşitli departmanları ve çalışanları arasındaki bölünmesine karşılık gelir. Bütçe finansal hizmetler tarafından hazırlanıyorsa, fon harcama talepleri, şirketin karşı taraflarıyla doğrudan etkileşimde bulunan çalışanlar ve departmanlar tarafından oluşturulur.

Yapılandırmada parasal belgeler oluşturulur (ödeme emirleri, kasa makbuzları ve borç emirleri vb.), “Banka Müşterisi” gibi özel bankacılık programlarıyla etkileşim sağlanır, finansal akışlar kontrol edilir ve depolama alanlarındaki fonların kullanılabilirliği sağlanır. izlendi. Yabancı para cinsinden nakit ödeme imkanı sağlanmaktadır.

“Fon harcama talebi” belgesi, nakit veya nakit dışı ödeme (ödeme grubu) yapma veya fon taşıma kararını kaydetmeyi amaçlamaktadır. Belge detayları ve kullanım prosedürü temel olarak “Ödeme emri (giden)” ve “Nakit harcama emri” belgelerine benzer.

Rezervasyon ve yerleştirme parametreleri otomatik olarak doldurulabilir. Bu amaçla belgede bayraklar ve "Otomatik yerleştirme".

Bu bayraklar ayarlanmışsa, düğmeye tıkladığınızda “Yerleşim” sütunu otomatik olarak doldurulabilir. "Doldur ve Gönder".

Otomatik ve manuel yerleştirme şeması birleştirilebilir. Bayraklar ayarlandığında "Otomatik rezervasyon" Ve "Otomatik yerleştirme" Başvuru tutarının bir kısmı için yerleştirme seçeneğini manuel olarak belirleyebilirsiniz. Daha sonra düğmeye bastığınızda "Doldur ve Gönder" Yalnızca kalan tutar için otomatik yerleştirme yapılacaktır.

İşlem türü " olarak ayarlandığında Tedarikçiye ödeme" veya " Alıcıya iade" karşı taraflarla yapılan operasyonel anlaşmalarda değişiklikler yapılır.

“Harcama başvurusu” belgesine dayanarak banka ve nakit ödeme belgeleri girilebilir. Bu tür belgeler şu gerekliliği sağlar: Başvuru", siz yazarken buna göre doldurulur veya manuel olarak doldurulabilir. Ödeme belgelerini belirli bir fon harcama başvurusuyla gönderirken, belge tutarının bu başvuruya ilişkin mevcut ödenmemiş ödemeler bakiyesine uygunluğu kontrol edilir.

Ek haklar ayarlarken, kullanıcının para harcama başvurusunu belirtmeden ödeme belgelerini işlemesini yasaklamak mümkündür.

“Fon harcama talebi” belgesi aynı zamanda nakit yönetimi alt sistemi ile bütçeleme alt sistemi arasında bir bağlantı görevi görebilir. Bu amaçla uygulama “Bütçe Operasyonu” belgesine benzer bir detay bloğu (planlama senaryosu, ciro kalemi, merkezi finans bölgesi, proje vb.) sağlar. Belirtilen ayrıntılar kullanılarak, başvuru yapılırken harcama için onaylanan toplam fon miktarının önceden belirlenmiş sınır değerlere uygunluğu izlenir.

Uygulama onay mekanizmasını kullanırken uygulamalarla çalışmanın özellikleri

Başvuru onay mekanizması isteğe bağlı olarak kullanılır: kuruluşların listesi için.

Uygulama eşleştirme mekanizmasını kullanırken aşağıdaki özellikler ortaya çıkar:

Başvuruda bir kuruluş belirtilmemişse bu başvuru onaya katılmaz.

Başvurunun onaylanma yolu, başvuruda belirtilen Bölüme bağlı olarak ayarlar doğrultusunda belirlenir.

Başvuru onay yolunu geçmemişse (başvuru durumu “Onaylandı” değilse) buna dayanarak ödeme belgesi düzenlenemez.

Başvuru onay yoluna gitmeye başlarsa başvuruda değişiklik yapılabilir

Başvurusu şu anda onaylanmakta olan kullanıcı

Bir uygulamayı daha yüksek onay aşamalarında onaylayan kullanıcılar
Diğer kullanıcılar uygulamayı değiştiremez.

Sipariş "Onaylandı" durumunda ise değiştirilemez

Başvuru “Reddedildi” durumuna girerse başvuru iptal edilir

Başvuruların güncel durumu başvurular listesindedir

durum ayrı bir sütunda görüntülenir

Sipariş durumuna göre gruplama kullanılıyor

uygulamalar arka plan rengiyle vurgulanır
- reddedildi - pembe

Yazının ikinci bölümünde “Fon harcama taleplerinin” oluşturulması, onay yolundan geçirilmesi ve oluşturulan uygulamaya göre fon verilmesi prensibini ele alacağız.
Bir örneğe bakalım:

Tedarik muhasebecisi, IP Dobronravov tedarikçisine malzeme temini için avans ödemesi yapmak amacıyla fon harcaması talebinde bulunur;
CFO'nun başvuruyu incelemesi ve onaylaması gerekir;
Onaylanan başvuruya dayanarak, satın alma muhasebecisi bir nakit makbuz siparişi oluşturur (“Ödendi” işareti olmadan, ancak “Operasyonel muhasebeye yansıt” işaretiyle);
Nakit makbuz siparişini kontrol eden kıdemli kasiyer, parayı çıkarır (ve belgeyi "Ödendi" olarak işaretler);
Nakit işlemler muhasebecisi, nakit girişi sırasını kontrol eder (muhasebe ve vergi muhasebesi girişlerinin oluşturulması için muhasebe ve vergi muhasebesi kayıtlarına yansıması için kutuyu işaretler).

İşlemlerin yansıtılmasını kolaylaştırmak için arayüzü “Nakit Yönetimi” olarak değiştirelim.
Fon harcama başvurularıyla çalışmaya başlamadan önce tüm bilgileri girmelisiniz. arkaplan bilgisi. Doldurmanız gereken ilk şey, “Fon harcama başvurularını onaylama ayarları” bilgi kaydıdır. “Başvuruların onaylanmasının ayarlanması” bölümünde bu mekanizmanın kullanıldığı kuruluşlar ve onay mekanizmasının kullanılmaya başlanacağı tarih belirtilir. Bu ayar, programın StroyTorg LLC kuruluşunun 01/01/2013 tarihinden itibaren fon harcama taleplerini onaylamak için bir mekanizma kullanacağını belirleyebilmesi için gereklidir.

Koordinasyon rotalarının yapılandırılması da gereklidir (Şekil 2). Bu ayar, “Onay yollarının başlatılmasına ilişkin ayarlar” bilgi kaydında belirtilir: onay yollarının departmanlara uygunluğu belirlenir. Onay rotası (“Onay Rotaları” dizini) aşamayı ve bu aşamadaki onaylayan kişilerin listesini gösterir. Örneğimizde, oluşturulan başvurunun öncelikle mali direktör tarafından bir aşamadan onaylanması gerekecektir.

Ayrıca “Fon harcama başvurularının onaylanmasının ayarlanması” (Şekil 1) bilgi kaydını kurmanız ve başvuruları onaylamanın aşamalarını (rotasını) belirlemeniz gerekir (Şekil 2).

Pirinç. 1

Pirinç. 2

Koordinasyon rotası Başvuru, ayarlara uygun olarak ve başvuruda belirtilen departmana bağlı olarak belirlenir.

Not bir bölümün yalnızca bir koordinasyon rotasına karşılık gelmesi gerekir. Her bölüm için bir onay rotası belirlenmelidir, aksi takdirde bu bölüm için oluşturulan tüm başvuruların onay süreci işlemeyecektir.

1. Satın alma muhasebecisi “Fon harcama talebi” belgesini oluşturur.

Seçtiğimiz “Nakit Yönetimi” arayüzünde “Planlama” - “Talepler” - “Para harcama talebi” menü öğesine gidin (Şekil 3). “Hazırlandı” durum türüyle bir “Para harcama başvurusu” oluşturalım (Şekil 5)

Uygulama, “Nakit çıkış talimatı” ve “Giden ödeme talimatı” işlem türlerini tekrarlayan çeşitli işlem türlerine sahiptir (Şekil 4)

"Karşı taraflarla yapılan ödemeler" sekmesindeki "Para harcama talebi" bölümünde temel bilgiler belirtilir: fon verilmesi gereken ödemenin karşı tarafının yanı sıra anlaşma, tutar, organizasyon, bölüm ve durum.

“Açıklama” sekmesinde belirtebilirsiniz Ek Bilgiler Herhangi bir biçimde.

“Tahsis” sekmesi fon ayırma ve yerleştirme olanağı sağlar (Şekil 6). Bu, örneğimizde satın alma muhasebecisinin tedarikçiye avans ödemek için fon ayırabileceği ve fonların hangi kasadan verileceğini belirtebileceği anlamına gelir. Rezervasyon ve yerleştirme parametreleri otomatik olarak doldurulabilir. Belgede bu amaca yönelik işaretler bulunmaktadır. "Otomatik rezervasyon" Ve "Otomatik yerleştirme". Bu bayraklar ayarlanmışsa, düğmeye tıkladığınızda “Yerleşim” sütunu otomatik olarak doldurulabilir. "Doldur ve Gönder". Otomatik ve manuel yerleştirme şeması birleştirilebilir.

“Bütçeleme” sekmesindeki veriler, bütçeleme alt sistemi ile nakit yönetimi alt sistemi arasında bağlantı olarak kullanılabilir. Bu sekmede görüntülenen bilgiler, planlanan bütçeye uygun olarak kullanılması planlanan fon miktarının kontrol edilmesine yarar (Şekil 7).

Tedarik muhasebecisinin erişim hakları sınırlı olduğundan, "Fon harcama talebi" belgesinde yalnızca "Hazırlandı" durumunu ayarlayabilir ve "Onaylandı", "Ertelendi", "Kabul Edildi", "Reddedildi" gibi durumlar Uygulamanın onaylanmasından sorumlu kullanıcılar tarafından belirlenir.

2. Mali direktör, 120.000 ruble tutarındaki fon harcamasına ilişkin başvuruyu inceler ve onaylar.

Mali direktör, "Başvuru Onay Durumu" işlemini kullanarak değerlendirilmesi gereken başvuruların listesini analiz edebilir (Şekil 8).

"Uygulama Onay Durumu"nu işlemeye başladığınızda, "Hazırlandı", "Onaylandı", "Ertelendi", "Kabul Edildi", "Reddedildi" gibi belirli durumlara (durumlara) göre gruplandırılmış tüm uygulamaların bir listesi görüntülenir. Kolaylık sağlamak için, düğmeyi kullanarak örneğin bir gün, bir hafta, bir ay, on yıl, çeyrek yıl, altı ay, yıl vb. için "Dönemi ayarlama" seçimini yapabilirsiniz. Tüm başvurulardan yalnızca belirli bir süreye denk gelenler kalacaktır.

Fon harcama başvurularının durumunu örneğin "Hazırlandı" yerine "Onaylandı" olarak değiştirmek için başka bir işlem kullanmanız gerekir ("Başvuru Durumu").

Bu işlemde aşağıdakiler arasından seçim yapabilirsiniz: genel liste uygulamalar, örneğin “Onay bekleniyor”, “Ertelendi”, “Önceki aşamalarda onay bekleniyor”, “İşleniyor” durumundaki başvurular (Şekil 9).

İşleme, koordine edilmemiş uygulamaların bir listesini görüntüler ve uygulamanın durumunu değiştirebilirsiniz (Şek. 10). Bu işleme “Planlama” - “Talepler” - “Uygulamaların koordinasyonu” menü öğesinden ulaşabilirsiniz.

Finans Direktörü fon harcama talebini "Onaylayabilir", "Erteleyebilir" veya "Reddedebilir". “Durumu değiştir” - “Kabul ediyorum”u seçtiğinizde, onay kutuları onaylanması gereken uygulamaları işaretler. Sırada kalan diğer uygulamalar “Uygulamaların onayı” belge günlüğünde görüntülenebilir.

Başvuru onay yolunu geçmemişse (başvuru durumu “Onaylandı” değilse) bu durumda ödeme belgesi düzenlenemez.

Başvuru onay yoluna gitmeye başlarsa başvuruda değişiklik yapılabilir:

Başvurusu onaylanmakta olan kullanıcının;

Uygulamayı daha yüksek onay aşamalarında onaylayan kullanıcılar.

Diğer kullanıcılar uygulamayı değiştiremez.

Uygulama “Onaylandı” durumunda ise değişiklik yapılamaz (düzenleme için devre dışı kalır), dolayısıyla uygulamadaki alanlar satınalma muhasebecisi için gri olur ve değiştirilemez.

3. Onaylanan başvuruya dayanarak, satın alma muhasebecisi, IP Dobronravov tedarikçisine avans verilmesi için "Ödendi" işareti olmadan "Tedarikçiye ödeme" işlem türüyle bir nakit makbuz düzenler (Şekil 11)

Not Satınalma muhasebecisi tarafından oluşturulan nakit girişi siparişinde yalnızca “Yönetim muhasebesine yansıt” ve “Operasyon muhasebesine yansıt” onay kutularının işaretli olduğunu. Nakit makbuz emrinin doğru oluşturulduğu kontrol edildikten sonra kıdemli kasiyer tarafından “Ücretli” onay kutusu işaretlenmelidir. Ayrıca nakit makbuz siparişinde hangi uygulamayı oluşturduğumuzu da belirtiyoruz.

Nakit makbuz siparişinde yalnızca yönetim muhasebesi için onay kutuları varsa, bu tür bir belge kayıtlar (muhasebe kayıtları) oluşturmaz. Ancak birikim kayıtlarına giriş yapıyor: “Silinecek nakit” ve “Karşı taraflarla yapılan ödemeler” (Şekil 12). Bu bilgi “Ödenmemiş giden belgeler” bölümündeki “Ödeme takvimi” raporuna girer (Şekil 13).

4. Kıdemli kasiyer, nakit makbuz siparişini kontrol eder, "Ödendi" onay kutusunu işaretler ve parayı çıkarır.

Nakit tahsilat talimatı ödendikten sonra belgedeki alanlar gri renkte olur ve örneğimizde satın alma muhasebecisi ve diğer katılımcılar tarafından düzenlenemez. Belirli bir kullanıcı için hangi erişim haklarının yapılandırıldığına bağlı olarak, belirli belgeler, belgelerdeki alanlar vb. düzenleme için mevcut olabilir.

Not:Çok sayıda yazarkasa varsa ve her birinde "Ücretli" kutusunu işaretlemeniz gerekiyorsa, dizinlerin ve belgelerin grup olarak işlenmesini kullanabilirsiniz ("Hizmet" menü öğesi). Bu işleme tam arayüzdeki “Servis” menü öğesine giderek ulaşabilirsiniz (Şek. 14).

Ayrıntıları değiştirmek için “Ayarlar” düğmesine tıklayın ve “Nesne ayrıntılarının değiştirilmesine izin ver” bayrağını seçin. Analiz kolaylığı için “Tüm sütunları göster” bayrağını ayarlayalım (Şekil 15).

Grup işlemeyi kullanarak nakit giriş sırasına "Ödendi" işaretini koymak istiyoruz. Bunu yapmak için grup işlemenin "Seçim" bölümünde StroyTorg LLC kuruluşunu belirtiyoruz; “Ücretli” - “Hayır” seçeneğiyle yalnızca 01/01/2013 - 01/21/2013 dönemine ait işlenmiş belgeleri seçiyoruz.

“İşleniyor” sekmesindeki “Seç” düğmesine tıkladığınızda, “Ücretli” olarak işaretlemeniz gereken belgeler görünecektir (Şek. 16). "Eylem" satırında "Ayrıntıları değiştir[Bağlantı.Ücretli] - Yükle'yi seçin. Ve koş".

Ayrıntıların değerini değiştirdikten sonra, değiştirilen belgeleri yeniden göndermeniz gerekir: “Eylem” alanında “Değiştir: [Belgeleri gönder] – Ayarla - “Çalıştır” seçeneğini seçin (bkz. Şekil 17).

5. Kasa muhasebecisi, nakit makbuz sırasını kontrol eder (muhasebe ve vergi muhasebesi girişlerinin oluşturulması için muhasebe ve vergi muhasebesi kayıtlarına yansıması için kutuyu işaretler).

Ayrıca, örneğin iş gününün sonunda bir nakit işlemleri muhasebecisi, "Ödendi" olarak işaretlenen tüm nakit çıkış siparişlerini kontrol eder ve belgenin muhasebe ve vergi muhasebesi girişleri oluşturması için belgedeki BU ve NU kutularını işaretler. (Şekil 18)

Not: BU ve NU kutularını işaretlemeniz gereken çok sayıda nakit makbuz siparişi varsa, “Referans kitaplarının ve belgelerin grup olarak işlenmesini” kullanabilirsiniz (Şekil 19).

Dizinlerin ve belgelerin grup halinde işlenmesinde, tablo kısmında "Muhasebeye yansıt" onay kutusunu işaretlemeniz gereken "Nakit harcama emri [TC: Ödeme Kod Çözme]" belgelerini seçiyoruz.

“Seçim” alanında hangi kuruluş için belgeleri seçmemiz gerektiğini belirtiyoruz, yalnızca 01/01/2013 ile 01/21/2013 tarihleri arasında işlenen belgelerle (ve ayrıca içinde yer alan nakit makbuzlarla) ilgilendiğimizi belirtiyoruz. “Muhasebeye yansıt” onay kutusu işaretli değildir) muhasebe"). Tüm parametreleri doldurduktan sonra “Seç” düğmesine tıklayın: belirtilen koşulları karşılayan belgeler seçilecektir. İşleme penceresinin alt kısmında “Nitelikleri değiştir” - “Yansıt” seçeneğini seçin muhasebe" - "Yükle" ve "Çalıştır" düğmesini tıklayın. Belgeler işlendikten sonra yeniden gönderilmeleri gerekir (Şekil 16). O zaman aynı şeyi tekrarlamanız gerekir, ancak “Vergi muhasebesine yansıt” kutusunu işaretlemeniz gerekir.

“Nakit harcama emri” belgesini gönderirken, yalnızca muhasebe hesaplarında değil aynı zamanda kayıtlarda da hareketler oluşturulur (Şekil 20, 21)