UT sürüm 11'in yapılandırmasında bir şekilde düzeni geri yüklemeye karar verdik. Ve işte... Mal dengeleri kuruluşların dengeleriyle eşleşmiyor (birkaç kuruluş kullanılıyor) ve mal sevkiyatlarında hiç yakın değiller ve hatta normal ticaretle birlikte komisyon ticareti bile kullanılıyor. Kısacası, her şey o kadar ihmal ediliyor ki sıfırdan başlamak daha kolay, AMA... Sıfırdan başlayamazsınız - kurumsal muhasebe 3.0 (dizinler, belgeler) ile bir bağlantı var ve orada raporlama zaten gönderildi. Muhasebe bölümünde ayrı, muhasebe bölümünde ayrı ayrı işleri düzene koymaya karar verdik. Özellikle UT için karar verdik: mallarla ilgili her şeyi sıfırlıyoruz (depodaki mallar, kuruluşların malları, kuruluşların mallarının sevkiyatları ve komisyonla ilgili kayıtlar), ardından hayali bir makbuz yapıyoruz (komisyon dahil), ve karşılıklı yerleşimleri ayarlayarak karşılıklı yerleşimleri düzeltiriz. İlk başta belirli kayıtlar için yazmaya başladım, yazarken yaklaşık aynı sürede evrensel bir kayıt yazmayı düşündüm, ancak daha sonra on kez yeniden yazmak zorunda kalmamak için tüm kayıtlar için uygun olurdu . Yönetilen formlara yönelik Retail 2, Complex ve diğer yapılandırmalara da uygun olmalıdır. UT11'de test edildi.
Nasıl kullanılır. Öncelikle manuel olarak boş bir “kayıt ayarlama” belgesi oluşturuyoruz, tarih ve saati ayarlıyoruz (çeyrek sonu 23:59:59 ayarladım), kasa bakiyeleri tam olarak bu konuma (belge konumu) alınacak, genel olarak, belgeden yalnızca pozisyona ve ihtiyaç duyduğumuz yere ihtiyacımız var. Daha sonra hangi kayıtları sıfırlamamız gerektiğini seçip “Oluştur”a tıklıyoruz. Raporları ve/veya evrensel bir raporu kullanarak ayarlamayı açarız, bakarız, kayıtları kontrol ederiz. Bakiyeler tüm boyutlar ve tüm kaynaklar için kapalıdır. Ayrıca formda organizasyona ve depoya göre bir seçim var (orijinal versiyondan bir gerileme, ancak işe yarıyor), başka seçimler eklemedim (hiç ihtiyacım olmadığı için), kimin ihtiyacı olursa olsun, yapabilirsin kendiniz ekleyin, modülde her şey açıkça yazılıyor ve kullanmaya başlamadım çünkü örneğin kuruluşa göre bir seçim yaparsanız, o zaman "Kuruluşların malları" kaydı için seçim işe yarayacaktır, ancak kayıt için " Depolardaki mal” olmayacağı için (böyle bir ölçüm yok) seçim yapmadan sıfırladım.
Bir süre geçti...
Yeni bir sürüm yayınlandı, artık işleme, dolaşımdaki birikim kaydındaki hareketleri tersine çevirmeyi öğrendi (daha önce hata veriyordu - yani aslında yalnızca denge kayıtlarıyla çalışıyordu). Üstelik hareketler tersine çevrilmiştir; UT11'deki kayıt defterine bakarsanız "Satışlar" deyin, o zaman tersine çevrildikten sonra satışlar hiç gösterilmeyecektir, yani. sanki hiç satış yokmuş gibi - dönemin cirosunun tamamı boş olacak. Bir kez daha - öyle görünüyor ki, örneğin 1-30 Ocak dönemi için satışlarımız vardı, 31'inde geri dönüş yapıyorum, ardından 1'den 30'a kadar rapora bakarsam - 31'den 30'a kadar satışları göreceğim 31 - Ters hareketler göreceğim, 1 - 31 - arası boş gösterecektir. Mesela UT11 ve Perakende 2.2'de “Kasa” kasasını düzene koymak zorunda kaldığımda (50 hesap, kim bilir) kasanın hareketlerini tersine çevirdim.
Evet, söylemeyi unuttum, “Başlangıç Tarihi” alanı belirdi - ciro kayıtları için dönemin başlangıç tarihini ayarlamak için kullanılır (tabii ki bakiyeler için geçerli değildir), “Kayıt Ayarlaması” belge konumu Dönemin bitiş tarihi olarak kullanılır (ciro kayıtları için) - yani . bakiye kaydına gelince (bakiyeler belge pozisyonuna kaldırılır). Ciro kayıtları için “Başlangıç Tarihi” boş kalabilir - bu durumda var olabilecek en erken tarih olarak algılanır ve ciro kaydı için muhasebe başlangıcından “pozisyona” kadar olan tüm hareketlerin olduğu anlamına gelecektir. Kayıt Ayarı” belgesi ters çevrilmiştir.
İyi haber; puan cinsinden maliyet azaldı.
- Terazilerin hızlı ve rahat sıfırlanması;
- Basit ve gelişmiş arayüzler;
- Birikim ve muhasebe kayıtları için destek(yazışmanın etkin ve devre dışı olduğu durumlar dahil; hesap planı olsun veya olmasın);
- Çoğu konfigürasyonu destekler;
- Yalnızca standart olanlarla değil, herhangi bir konfigürasyon kaydıyla çalışabilme yeteneği;
- Esnek seçim ayarları(boyutlara, ayrıntılara, kaynaklara ve ayrıca iç içe geçmiş alanlara göre seçim. “VE”, “VEYA”, “DEĞİL” gruplarının kullanımı. ACS'ye dayalı);
- Her şeyi sıfırlama yeteneği değil, ama yalnızca gerekli kaynaklar;
- Alanların doldurulması düzeltildi. hesaplar muhasebe kaydı (alt hesap, bilanço dışı ölçümler ve kaynaklar) ve seçilen değerlere sahip tüm ayrıntılar için;
- Ayarlama belgesinin türünü seçme yeteneği (yapılandırma, kaydı çeşitli belge türleriyle ayarlamanıza izin veriyorsa);
- Hareketleri yeni bir belgeye veya önceden oluşturulmuş bir belgeye kaydetme yeteneği;
- Çoklu mod desteğiİşler:
- Dt'de sıfırlanabilir hesap (muhasebe kayıtları için);
- Kt cinsinden sıfırlanabilir hesap (muhasebe kayıtları için);
- Olumlu kaynak değerleri;
- Negatif kaynak değerleri.
- Standart olmayan konfigürasyonlarda çalışın (eğer buna standart bir konfigürasyon ayarlama belgesi eklerseniz (desteklenenler listesinden));
- Esnek arayüz: yalnızca seçilen kayıt için geçerli konfigürasyonda gerekli olan alanlar görüntülenir;
- Bağlantı harici işlem olarak.
Gözden geçirmek
İşleme varsayılan olarak basit bir arayüzde açılır. Minimum alan içerir ve kaydın tamamını sıfırlamanıza olanak tanır. Daha fazla ayara ihtiyacınız varsa “Gelişmiş modu etkinleştir” düğmesine tıklamanız gerekir.
Gelişmiş mod arayüzü birkaç bölüme ayrılabilir:
1. Vaka seçim alanları.
Kayıt adlarını içeren açılır liste, dolaşımdaki kayıtlar hariç (bakiyeleri yoktur) tüm kayıtları içerir.
2. Ayarlama belgesi ayarları alanları.
Duruma göre bazıları gizlenmiş olabilir.
“Belgede ayarlamalar yapın...” alanına özellikle değinilmelidir. İçinde hareket oluşumu modlarından birini seçebilirsiniz:
- "Gelen" görünümüne sahip tüm hareketler (birikim kayıtları için mod);
- "Tüketim" görünümüne sahip tüm hareketler (birikim kayıtları modu);
- Dt'de sıfırlanabilir hesap (muhasebe kayıtları için). Ayarlama belgesi formun işlemlerini oluşturacaktır Dt<Счет>BT<КоррСчет> ;
- Kt cinsinden sıfırlanabilir hesap (muhasebe kayıtları için). Ayarlama belgesi formun işlemlerini oluşturacaktır Dt<КоррСчет>BT<Счет> ;
- Pozitif kaynak değerleri (bu mod, örneğin negatif miktarların kayda yazılamadığı durumlarda faydalıdır);
- Negatif kaynak değerleri (sıfırlama sırasında ciroyu azaltmanız gerekiyorsa).
3. Tarih ve ayar belgesi alanlarını sıfırlayın.
"Tarih itibarıyla bakiye sıfırla" alanında sıfırlama için bakiyenin alınacağı tarih ve saati belirtmeniz gerekmektedir. Artıkları alırken hareket son saniyede devreye girer.
Düzenleme belgesinin türüne bağlı olarak "Yorum" ve/veya "Organizasyon" alanları mevcut olacaktır. Bu alanların değerleri ayar belgesine aktarılacaktır.
4. “Hesap ve doğru hesap”, “Ayrıntılar”, “Kaynaklar” ve “Çizimler” yer imleri.
Seçilen kayda bağlı olarak bazıları gizlenmiş olabilir.
Açık "Hesap ve muhabir hesap" sekmesi “Hesap”ı seçin (sıfıra sıfırlanacaktır). Ayrıca gerekirse “Muhabir hesap”, onun alt hesabı, bilanço dışı ölçümleri ve kaynakları da seçebilirsiniz. Bu alanların değerleri “İlgili hesap” yanındaki tüm işlemlere eklenecektir.
Açık "Ayrıntılar" sekmesi Ayarlama belgesinin tüm hareketlerinde değiştirilecek detayların değerlerini seçebilirsiniz.
Açık "Kaynaklar" sekmesi sıfırlanması gerekenleri işaretlemeniz gerekir (hepsi varsayılan olarak seçilidir). Örneğin “Miktar”ı değiştirmeden yalnızca “Tutarlar”ı sıfırlayabilirsiniz.
Açık "Seçimler" sekmesi
gerekli koşulları seçebilirsiniz. Örneğin, tüm bakiyeleri değil, yalnızca belirli bir kuruluşla ilgili olanları sıfırlamanız gerekiyorsa. Veya yalnızca negatif bakiyeye sahip olanlar.
Seçimleri belirlerken iç içe geçmiş alanları ve “VE”, “VEYA”, “DEĞİL” gruplarını seçebilirsiniz.
Herhangi bir alan veya kayda, hakları yoksa veya program ayarlarında (işlevsel seçenekler) devre dışı bırakıldıysa erişilemeyebilir.
Mevcut konfigürasyonda hangi ayar belgelerinin “testere” işlediğini öğrenmek için “Ayar Belgesi” alanının sağındaki soru işaretine tıklamanız gerekmektedir.
Uyumluluk
İşleme öncelikle arayüz odaklı sistemler için tasarlanmıştır. Eski arayüzde geliştirilen sistemlerde de çalışacaktır ancak bazı kısıtlamalarla. Ayrıntılar Tablo 1'de.
Ayarlama belgelerinde hareket yapmak için kullanılan tüm kayıtları sıfırlayabilirsiniz.
Tablo 1. İşlemenin test edildiği konfigürasyonlar
| Yapılandırma | Sürüm | Desteklenen Ayarlama Belgeleri |
|---|---|---|
| ERP2.4 | 2.4.5.118 2.4.6.160 |
Ayarlamaları kaydedin Veri aktarımı |
| Devlet muhasebesi kurumlar 1.0 * |
1.0.53.4 | Operasyon (muhasebe) |
| Devlet muhasebesi kurumlar 2.0 |
2.0.58.23 | Operasyon (muhasebe) Ayarlamaları kaydedin |
| Kurumsal muhasebe 3.0 | 3.0.37.25 | Operasyon |
| Kurumsal muhasebe CORP 2.0 * | 2.0.64.20 | Operasyon (muhasebe ve vergi muhasebesi) |
| Kurumsal muhasebe CORP 3.0 | 3.0.39.67 3.0.65.80 3.0.67.38 |
Operasyon |
| ŞİRKET 2.5 * |
2.5.134.1 | Veri aktarımı Biriktirme kaydı girişlerini ayarlama |
| Maaş ve İK yönetimi ŞİRKET 3.1 |
3.1.7.144 | Veri aktarımı |
| Maaş ve İK yönetimi Beyaz Rusya 3.0 için |
3.0.10.109 | Veri aktarımı |
| Kapsamlı otomasyon 1.1 * | 1.1.107.4 | Kayıt girişlerini ayarlama Veri aktarımı |
| Kapsamlı otomasyon 2.4 | 2.4.5.118 | Operasyon (düzenlenmiş muhasebe) Ayarlamaları kaydedin Veri aktarımı |
| Küçük bir şirketi yönetmek 1,6** | 1.6.15.65 | Ayarlamaları kaydedin Operasyon |
| Üretim Yönetimi kurumsal 1.3 * |
1.3.106.2 | Kayıt girişlerini ayarlama Operasyon (muhasebe ve vergi muhasebesi) Veri aktarımı |
| Ticaret Yönetimi 10.3* | 10.3.42.1 | Kayıt girişlerini ayarlama |
| Ticaret Yönetimi 11.4 | 11.4.5.111 | Ayarlamaları kaydedin |
| Holding yönetimi 1.3 | 1.3.12.1 | Operasyon IFRS Operasyonu |
| Holding yönetimi 3.0 | 3.0.3.20 | Operasyon IFRS Operasyonu |
| * Eski arayüze sahip sistem. Harici işlem olarak bağlanamaz. Çalışmak için, onu konfigürasyona dahil etmeniz (önerilir) veya sistemi yönetilen arayüzde çalıştırarak “Dosya” - “Aç” aracılığıyla açmanız gerekir. ** UNF 1.6 için muhasebe kaydında yalnızca gerçek veriler sıfıra sıfırlanabilir. Biriktirme kayıtları için herhangi bir kısıtlama yoktur. |
||
Tedavi kalın ve ince müşteriler için tasarlanmıştır.
Kod açık.
UT sürüm 11'in yapılandırmasında bir şekilde düzeni geri yüklemeye karar verdik. Ve işte... Mal dengeleri kuruluşların dengeleriyle eşleşmiyor (birkaç kuruluş kullanılıyor) ve mal sevkiyatlarında hiç yakın değiller ve hatta normal ticaretle birlikte komisyon ticareti bile kullanılıyor. Kısacası, her şey o kadar ihmal ediliyor ki sıfırdan başlamak daha kolay, AMA... Sıfırdan başlayamazsınız - kurumsal muhasebe 3.0 (dizinler, belgeler) ile bir bağlantı var ve orada raporlama zaten gönderildi. Muhasebe bölümünde ayrı, muhasebe bölümünde ayrı ayrı işleri düzene koymaya karar verdik. Özellikle UT için karar verdik: mallarla ilgili her şeyi sıfırlıyoruz (depodaki mallar, kuruluşların malları, kuruluşların mallarının sevkiyatları ve komisyonla ilgili kayıtlar), ardından hayali bir makbuz yapıyoruz (komisyon dahil), ve karşılıklı yerleşimleri ayarlayarak karşılıklı yerleşimleri düzeltiriz. İlk başta belirli kayıtlar için yazmaya başladım, yazarken yaklaşık aynı sürede evrensel bir kayıt yazmayı düşündüm, ancak daha sonra on kez yeniden yazmak zorunda kalmamak için tüm kayıtlar için uygun olurdu . Yönetilen formlara yönelik Retail 2, Complex ve diğer yapılandırmalara da uygun olmalıdır. UT11'de test edildi.
Nasıl kullanılır. Öncelikle manuel olarak boş bir “kayıt ayarlama” belgesi oluşturuyoruz, tarih ve saati ayarlıyoruz (çeyrek sonu 23:59:59 ayarladım), kasa bakiyeleri tam olarak bu konuma (belge konumu) alınacak, genel olarak, belgeden yalnızca pozisyona ve ihtiyaç duyduğumuz yere ihtiyacımız var. Daha sonra hangi kayıtları sıfırlamamız gerektiğini seçip “Oluştur”a tıklıyoruz. Raporları ve/veya evrensel bir raporu kullanarak ayarlamayı açarız, bakarız, kayıtları kontrol ederiz. Bakiyeler tüm boyutlar ve tüm kaynaklar için kapalıdır. Ayrıca formda organizasyona ve depoya göre bir seçim var (orijinal versiyondan bir gerileme, ancak işe yarıyor), başka seçimler eklemedim (hiç ihtiyacım olmadığı için), kimin ihtiyacı olursa olsun, yapabilirsin kendiniz ekleyin, modülde her şey açıkça yazılıyor ve kullanmaya başlamadım çünkü örneğin kuruluşa göre bir seçim yaparsanız, o zaman "Kuruluşların malları" kaydı için seçim işe yarayacaktır, ancak kayıt için " Depolardaki mal” olmayacağı için (böyle bir ölçüm yok) seçim yapmadan sıfırladım.
Bir süre geçti...
Yeni bir sürüm yayınlandı, artık işleme, dolaşımdaki birikim kaydındaki hareketleri tersine çevirmeyi öğrendi (daha önce hata veriyordu - yani aslında yalnızca denge kayıtlarıyla çalışıyordu). Üstelik hareketler tersine çevrilmiştir; UT11'deki kayıt defterine bakarsanız "Satışlar" deyin, o zaman tersine çevrildikten sonra satışlar hiç gösterilmeyecektir, yani. sanki hiç satış yokmuş gibi - dönemin cirosunun tamamı boş olacak. Bir kez daha - öyle görünüyor ki, örneğin 1-30 Ocak dönemi için satışlarımız vardı, 31'inde geri dönüş yapıyorum, ardından 1'den 30'a kadar rapora bakarsam - 31'den 30'a kadar satışları göreceğim 31 - Ters hareketler göreceğim, 1 - 31 - arası boş gösterecektir. Mesela UT11 ve Perakende 2.2'de “Kasa” kasasını düzene koymak zorunda kaldığımda (50 hesap, kim bilir) kasanın hareketlerini tersine çevirdim.
Evet, söylemeyi unuttum, “Başlangıç Tarihi” alanı belirdi - ciro kayıtları için dönemin başlangıç tarihini ayarlamak için kullanılır (tabii ki bakiyeler için geçerli değildir), “Kayıt Ayarlaması” belge konumu Dönemin bitiş tarihi olarak kullanılır (ciro kayıtları için) - yani . bakiye kaydına gelince (bakiyeler belge pozisyonuna kaldırılır). Ciro kayıtları için “Başlangıç Tarihi” boş kalabilir - bu durumda var olabilecek en erken tarih olarak algılanır ve ciro kaydı için muhasebe başlangıcından “pozisyona” kadar olan tüm hareketlerin olduğu anlamına gelecektir. Kayıt Ayarı” belgesi ters çevrilmiştir.
İyi haber; puan cinsinden maliyet azaldı.
Kayıtlarla çalışmayı öğrenme (1C: Muhasebe 8.3, baskı 3.0)
2016-12-08T13:50:45+00:00Sevgili okuyucular, bu derste 1C'de çalışırken son derece önemli bir konuya değinmek istiyorum: Muhasebe 8.3 - Kayıtlar.
Bunun neden bu kadar önemli olduğunu size hemen küçük bir örnekle göstereceğim.
Ocak ayı maaş bordromuzu alalım:
Şubat ayının başında kasadan maaş bordrosu oluşturup “Doldur” butonuna tıklıyoruz:
Ve aşağıdakileri elde ederiz:
Ancak Ocak ayı için:
- 50.000 ruble tahakkukları
- Kişisel gelir vergisi 6.500 ruble
- Ödenecek toplam 43.500 ruble
Hata nerede ortaya çıktı? Bir şeyler yanlış gitti? Ödenecek tutarı artık her zaman manuel olarak girmek gerçekten mümkün mü?
Deneyimli bir muhasebeci derhal hesap 70 için bir bilanço hazırlayacaktır:
Ve daha da şaşkına dönecek çünkü rapora göre aynı 43.500 kişinin hâlâ ödemesi gerekiyor! Peki fazladan 5.000 ruble nereden geldi?
Üstelik böyle bir durum (herhangi bir hesaplamayla) hem "troyka"da hem de "iki"de meydana gelebilir.
Bugün gizlilik perdesini kaldırmaya çalışacağım - neden bazen program bu kadar tuhaf davranıyor. Bu gibi durumlarda hatayı nasıl bulup düzeltebileceğinizi anlatacağım. Yazının sonuna doğru bu 5.000 rublenin nereden geldiğini öğreneceğiz.
O zaman hadi gidelim!
Kayıtları görmeyi öğrenme
Belgeleri gönderirken, 1C:Muhasebe 8 muhasebe hesaplarına giriş yapar (herhangi bir belge için DtKt düğmesi):
Tüm muhasebe raporları bu işlemler temelinde oluşturulur: Hesap analizi, Hesap kartı, Bilanço...
Ancak program tarafından ilanlara paralel olarak yazılan ve diğer her şey için kullanılan çok büyük bir veri katmanı var: alım satım kitabı olan KUDIR'ın doldurulması, düzenlenmiş raporlama... ödenecek ücretler, Sonunda
Muhtemelen zaten tahmin ettiğiniz gibi, bu katmana denir kayıtlar, işte burada:
Şimdi kafanızı daha fazla karıştırmamak için kayıtların açıklamasının ayrıntılarına girmeyeceğim.
Sadece programın davranışını daha iyi anlamak ve gerektiğinde düzeltmek için bu kayıtlardaki hareketleri "görmeyi" yavaş yavaş öğrenmemizin bizim için hayati önem taşıdığını söyleyeceğim."Ödenecek maaşlar" kaydına daha yakından bakalım - sorunumuzu ekstra 5.000 ile çözmek için mantıklı olan şey budur:
Bu kayıtta geliş yani artı şeklinde yapılmış iki giriş görüyoruz. Ekranı sağa kaydırırsak ilk satırda ödenecek tutarı “-6.500”, ikinci satırda ise “50.000” göreceğiz.
Bu kasadaki -6.500 + 50.000 bakiyesi 43.500'e eşit olup, “Doldur” butonuna tıkladığımızda “Kasadan ödeme ekstresi” belgesine dahil edilmesi gerekir.
Bir kez daha tekrarlıyorum - ödeme ekstresi çalışana olan borçlarımızı hesap 70'e göre değil, "Ödenecek maaşlar" kaydına göre belirler.
Meğerse ödenecek maaşın bu sicile göre doldurulduğunu biliyoruz ama sicil kayıtlarını görünce bile neyin yanlış olduğunu anlayamıyoruz.
Büyük olasılıkla, resmin tamamını göremiyoruz (belki bu kayıt için başka kayıtlar da vardır) ve muhasebe raporlarına benzer şekilde kaydı analiz etmek için bazı araçlar kendini göstermektedir.
Kayıtları analiz etmeyi öğrenme
Ve böyle bir araç var, adı " Evrensel rapor".
"Raporlar" bölümüne gidin ve "Evrensel rapor"u seçin:
“Birikim Kaydı” kayıt tipini, “Ödenecek Maaş” kaydını seçin ve “Oluştur” düğmesine tıklayın:
Pek bilgilendirici olmadığı ortaya çıktı:
Bunun nedeni, raporun ön kurulumunun gerekli olmasıdır, “Ayarları göster” butonuna tıklayın ve “Gruplama” sekmesinde “Çalışan” alanını ekleyin:
“Seçimler” sekmesinde kuruluşumuz için bir seçim yapıyoruz:
"Oluştur" düğmesini tıklayın:
Şimdi bu daha ilginç. Çalışanımıza ödenecek bakiyenin aynı 48.500 ruble olduğunu görüyoruz!
Tekrar rapor ayarlarına gidin ve “Göstergeler” sekmesine yeni bir “Kaydedici” alanı ekleyin:
Raporu tekrar oluşturuyoruz:
Artık 31 Aralık 2014'teki operasyon (görünüşe göre bakiye girişi) sonucunda 5.000'in ortaya çıktığını açıkça görebiliyoruz.
Ve ya bu işlemi değiştirmemiz ya da "Ödenecek maaşlar" kaydını manuel olarak ayarlamamız ve bu 5.000 rubleyi örneğin 31 Aralık 2015'te kapatmamız gerekiyor.
İkinci yola gidelim. Dolayısıyla bizim görevimiz, 2016 yılı başında “Ödenecek Maaşlar” sicilinde çalışana herhangi bir borcun kalmamasını sağlamaktır.
Bu manuel işlemle yapılır.
Kayıtları ayarlamayı öğrenme
"İşlemler" bölümüne gidin ve "Manuel olarak girilen işlemler"i seçin:
2015 yılı sonunda yeni bir operasyon oluşturuyoruz:
"Diğer" menüsünden "Kayıtları seç..." seçeneğini seçin:
"Ödenecek maaş" kaydını belirtin ve Tamam'a tıklayın:
Görünen kayıt sekmesine gidin ve 5.000 ruble masraf yapın:
Bunu yaparak, 2016 yılı başında sıfıra ulaşmak için çalışan başına sicilden 5.000 ruble çıkarıyoruz.
Operasyonu gerçekleştiriyoruz ve evrensel raporu yeniden oluşturuyoruz:
Her şey yolunda gitti! 31 Aralık 2015 tarihli manuel operasyonumuzun bakiyeyi sıfıra getirdiğini ve tahakkuk sonrası ödenecek maaşın beklenen 43.500 TL'ye eşit olduğunu görüyoruz.
İnanılmaz. Şimdi bunu ödeme ekstresinde kontrol edeceğiz.
Ancak öncelikle bir başka önemli noktaya dikkatinizi çekmek istiyorum:
“Çalışan” grubunun başındaki ve sonundaki bakiyelerin saçmalık gösterdiğini lütfen unutmayın. Bu bir hata değil, 1c'nin mimari özellikleriyle ilgili dikkate alınması gereken bir nüanstır.
Hatırlamak. Evrensel bir raporun belgeye (kayıt memuruna) kadar ayrıntılı olarak görüntülenmesi durumunda, gruplandırmaya göre bakiyeler saçmalık gösterecektir.Çalışan gruplamasına göre bakiye talep ediyorsak öncelikle eklediğimiz “Kayıt Sorumlusu” göstergesini ayarlardan kaldırmamız gerekiyor.