1c satıcı yapılandırması ana yapılandırmadan farklıdır. Sağlayıcı yapılandırmasını geri yükle

Tablo 1

3) "A" ürünü ve "B" ürünü için ayrı ayrı devam eden çalışma standartlarındaki değişikliklerin hesaplanmasına ilişkin bir açıklama hazırlamak - tablo 2

Ürün için ay başında devam eden çalışmalarda standartlardaki değişiklikleri hesaplama tablosu

Tablo numarası 2

4) üretim ve yönetim tablosunun organizasyonu için maliyetlerin dağılımına ilişkin bir açıklama hazırlamak 3.

Üretim ve yönetim organizasyonu için maliyetlerin dağıtım tablosu

Tablo No.3

6) Çıktı tablosu 4'ün standart maliyetinin hesaplanması beyanında standart maliyetteki çıktıyı tahmin edin. Bu hesaplamanın verileri, maliyet muhasebesi sayfasını doldurmak için kullanılır.

Standart üretim maliyetini hesaplama sayfası

Tablo 4

7) "A" ürünü ve "B" ürünü için muhasebe tahminlerini ayrı ayrı doldurun - standart maliyetlendirme ve üretim maliyeti muhasebe tablosuna dayalı tablo 5.

"A" ve "B" ürünü için maliyet tahmininin raporlanması

Tablo 5

Yürütme Verileri

1. Normatif hesaplama, ovmak.

2. Ay başında devam eden işin kalıntıları, bin ruble.

6) Malzeme ve ücret dağıtım tablolarından alıntı.

4. Üretim ve yönetim organizasyonu için maliyetler, ovmak.

5. "A" - 400 adet ürün, "B" - 350 adet ürün üretiminden çıktı.

"Standart Sahil"

Firma sistemi kullanıyor. "Standart Sahil" cam bölümünde. standart maliyetler bir ürünün üretimi için aşağıdaki gibidir:

Düz malzemeler 60 kg * 1 c.u. = 60 c.u.

Direkt işçilik maliyeti 3 saat * 10 USD = 30 c.u.

ODA 3 saat * 8 c.u. = 24 c.u.

Toplam standart maliyet = 114 USD

Planlanan pilot projeler başına. 3 c.u. 1 saatlik doğrudan işçilik ve RKY postası için. 27000 c.u'ya eşittir. Bir ürünün standart fiyatı 145 USD'dir.

Ocak ayında, bölüm 1.800 adetlik normal üretim kapasitesinde 1.650 adet üretti, 1.500 adet sattı (1600 adetlik planlı satış).

Gerçek maliyetler bir ürün için:

Düz malzemeler 58kg * 1.1 c.u. = 63,8 c.u.

Doğrudan işçilik maliyetleri 3,1 saat * 10 c.u. = 31 c.u.

ODA 39930 c.u. / 1650 ürün = 24,2 c.u.

Toplam gerçek maliyet = 119 USD

Gerçek ODA gönderisi. 23000 c.u. Bir ürünün gerçek fiyatı 160 USD'dir. Tanımlamak:

1) doğrudan malzeme maliyetlerinde ve bileşenlerinde sapma.

2) doğrudan işçilik maliyetlerindeki ve bileşenlerindeki sapma.

3) RKY ve bileşenleri açısından sapma: 1) hacimde sapma ve kontrollü sapma; 2) RKY gönderisine göre sapma. ve bileşenleri; ODA'ya göre sapma başına. ve bileşenleri);

4) gelir farkı ve bileşenleri.

Üretim sürecinin sonucu maliyet kalemlerine bağlıdır, muhasebe departmanı üretim maliyetini oluşturmak için tüm birincil belgeleri işler, atölye ve depolardaki üretim malzeme varlıklarının kontrolünü ve hareketini sağlar. Ana sentetik üretim kaydı, hesap 20 "Temel üretim"dir.

Hesap 20'deki belgelerin devri

kabul Tedariküretime geçiş dahili belgelerle belirlenir:

• Maddi varlıkların serbest bırakılması için gereklilik;
• havai.

Üretim işçilerinin ücretleri hesaplanırken bir maaş bordrosu düzenlenir.

Vergilerin hesaplanmasına raporlama kayıtları eşlik eder. Üretim döngüsünün sonunda, tüm üretim maliyetleri, maliyetlerin üretim döngüsüne ayrıntılı olarak dahil edildiğini gösteren özet bir maliyet tablosuna dönüştürülür.

Hesap 20 için özet sayfasının kayıtları

Tamamlamak için muhasebe açılış bakiyesini, dönem cirosunu ve kapanış bakiyesini gösteren ciro sayfaları kullanılır. Hesap 20 için ciro sayfası, üretimde maliyet kalemlerinin kullanıldığını gösterir. Aşağıda böyle bir ifadenin bir örneği verilmiştir.

LLC "Romashka" satılık çocuk kıyafetleri üretiyor. Hesap 20'nin analizi bilançoya yansıtılır:

Açıklamadan, üretim maliyetinin 238.367,84 rubleye eşit maliyet miktarını içerdiğini görüyoruz.

Maliyet kalemleri listesinin sabitlenmesi gerektiğini dikkate almak önemlidir. Muhasebe politikası tüm muhasebecilerin giderlerin maliyet kalemlerine göre dağılımını bilmesi ve doğru bir şekilde oluşturması için işletmeler.

Ayrıntılı bir analitik analiz için, üretim sürecini mahsup hesaplarıyla tarihe göre gösteren ayrıntılı üretim maliyetleri muhasebesi beyanını kullanabilirsiniz.

Puanlar arasındaki ilişki, hangi puanların 20 puanına karşılık geldiğini gösteren sentetik bir analizdir. Bu analiz aşağıdaki satırlara göre derlenmiştir:

• Dt20 Kt02 - üretim ekipmanının amortismanı tahakkuk etti;
• Dt20 Kt10.71 - maddi varlıklar kullanıldı;
• Dt20 Kt60 - hizmet maliyetleri tahakkuk ettirilir;
• Dt20 Kt69 - sigorta primleri Emekli Sandığı, FFOMS, FSS'de tahakkuk ettirilir;
• Dt20 Kt70 - üretim işçilerine maaş tahakkuk ettirildi.

Her ayın sonunda, hesap 20 kapatılır ve hesap 90'a karşılık gelir ve aşağıdaki giriş yapılır:

Dt90 Kt 20 - 244.567,99 ruble. - düşülen üretim maliyetleri.

Kapanış bakiyesi 20, ayın kapanışından sonra sıfır olmalıdır, ancak devam eden çalışmalar nedeniyle kapanış bakiyesi sayısal olacaktır.

Üretim maliyet tablosunun işlevleri

Maliyetlerin uygun şekilde dağıtılması şunları sağlar:

• Üretim maliyetlerinin güvenilir yansıması;
• Fiili üretim maliyetinin hesaplanması;
• Maddi varlıkların rasyonel kullanımının analizi;
• Ürünlerin gerçek fiyatının belirlenmesi;
• Analize dayanarak, endüstriyel ve yönetsel nitelikte kararlar alın.

Hesap 20'nin borç bakiyesi, üretilen ürünlerin doğrudan maliyetlerini, yardımcı ve dolaylı maliyetleri, evlilikten kaynaklanan kayıpları yansıtır. Bkz. 23, 25, 26, 28.

Hesap 20'nin kredi bakiyesi, üretim sürecinin gerçek maliyetini yansıtır. Tutarlar, Dt hesabındaki 20 numaralı hesaptan düşülür. 40,43,90.

Muhasebe ve ekonomik yönetim muhasebesi için ana kriter, üretilen ürünlerin üretim maliyetleridir.

Yeni başlayanların sıklıkla kendilerini içinde buldukları tipik bir durumu düşünün. Diyelim ki tipik bir yapılandırma 1C var: Entegre Otomasyon 8. Başlangıçta, yapılandırma dağıtım kitinden kuruldu (diyelim ki 1.1.20.1 sürümü). Daha sonra, işletmenin özelliklerine uyum sağlama ihtiyacı nedeniyle, değişiklik olasılığı dahil edildi (yeni gelenler, aslında öyle olmasa da, çoğu zaman yanlışlıkla bu eyleme destek verme diyorlar).

Ve şimdi, bir süre sonra, oldukça değiştirilmiş, ancak yine de tipik (düzenlenmiş muhasebe amacıyla, düzenli olarak güncelliyoruz) bir konfigürasyona sahibiz. Bazı varsayımsal durumlara bir göz atalım:

1) Bir süre sonra sonraki güncelleme Ayın rutin kapanış işlemi sırasında ortaya çıkan bir hata ile ilgili olarak muhasebe departmanından bir mesaj alıyoruz. Bundan önce böyle bir hata yoktu, bu nedenle güncelleme suçlanacak. Oldukça tipik bir durum. Hatayı teşhis etmeye başlıyoruz ve bacakların VATAccountingFormationMovements genel modülünden büyüdüğünü görüyoruz. Bu modülün önemli ölçüde standart bir modüle dönüştürüldüğünü ve birleşmeden sonra bazı prosedürleri / işlevleri "kaybettiğimizi" (veya standart olanlarda sıklıkla olduğu gibi, başka bir ortak modüle "atladıklarını") anlamaya ve anlamaya başlıyoruz. Akıl inceliklerinde ortak modüller kendi aralarında tipik olarak, yükseltme aşamasında, yalnızca kullanıcıların çalışması sırasında kendini gösteren bir sorunu belirlemek her zaman mümkün değildir.

Dolayısıyla, anlamak için mevcut sürümün tipik bir yapılandırmasına ihtiyacımız olduğunu anlıyoruz (diyelim ki 1.1.23.1). Ama nereden alabilirim? Tanıdık bir franch varsa ve dağıtım kitini hızlı bir şekilde gönderebilirse - iyi, ancak orada olmadığını ve sorunu acilen çözmeniz gerektiğini varsayalım. (Varese teklif etmeyin!). Üstelik internet olmayabilir ve böyle bir durumda ne yapmalı? Bir kişinin bu sorunu çözmek için kurduğu sürece defalarca tanık oldu. yeni üs mevcut ilk dağıtımdan ve ardından temiz bir veritabanında "gerçekten nasıl olması gerektiğini" görmek için art arda en son sürüme güncellendi. Ve tabut her zamanki gibi yeni açıldı :)

Şimdi farklı çözümlere bakalım:

a) İlk seçenek: Menü -> Konfigürasyon -> Konfigürasyonları karşılaştırın, ardından tedarikçinin konfigürasyonunu seçin ve ana konfigürasyonla karşılaştırın.

Şaşırtıcı bir şekilde, bunu bilmeyenler var. Veya, her koşulda, dosyadaki yapılandırmayla Karşılaştır, birleştir öğesini kullanın (daha önce tipik bir .cf almış / almış).

b) Yalnızca değişiklikleri görmemiz değil, aynı zamanda birleştirmeyi de hemen gerçekleştirmemiz gerekiyorsa, ikinci yöntem uygundur.

Menü -> Yapılandırma -> Destek -> Destek ayarları ve alttaki Karşılaştır, birleştir düğmesine basın.

2) Başka bir durum: Diyelim ki bazı tipik kod parçalarını değiştirdik veya sildik ve bir süre sonra bir hata yaptığımız ortaya çıktı ve her şeyi geri döndürmemiz gerekiyor. Ve sıklıkla olduğu gibi, yapılan değişikliklerden önce kaydedilen konfigürasyonun yedeği yoktur. Ancak bu kod parçasının standart kodda olduğundan eminiz, bu nedenle satıcının yapılandırması sorunu çözecektir.

Doğal olarak, ilk durumda olduğu gibi yapabilirsiniz. Karşılaştırma işleminin bitmesini bekleyin ve yapılandırma karşılaştırma penceresinden tipik modülü açın ve oradan kodu kopyalayın.

Bazıları tam olarak bunu yapıyor, ancak yine büyük ölçüde değiştirilmiş olan SCP tipi bir canavarla uğraşıyorsak, karşılaştırma sürecinin sonu çok uzun zaman alabilir. Bir .cf dosyamız olsaydı, onu yapılandırma penceresinde açabilirdik (bu arada, tüm yeni başlayanlar da bu özelliği bilmiyor) ve gerekli kodu oradan kopyalayabiliriz.

Ve makul bir soru ortaya çıkıyor, sağlayıcı yapılandırmasını bir dosyaya nasıl hala kaydedebilirsiniz? Neden Yapılandırmayı ana yapılandırma için dosyaya kaydet veya Veritabanı yapılandırmasını veritabanı yapılandırması için dosyaya kaydet gibi bir menü öğesi yok. Ve satıcı yapılandırması için aynısı nerede? Aslında o da orada, sadece biraz daha derine gömülmüş durumda. Yani, hepsi aynı destek ayarları formunda.

Pek çok insan, değişim olasılığını mümkün kılmak ve bir daha asla geri dönmemek için bu formu yalnızca bir kez açar.

Ve bizim durumumuzda, konfigürasyonu bir dosyaya kaydetmeden bile bunu yapmak daha da kolaydı, Aç düğmesine tıklayın. Etki aynı, ancak çok daha hızlı.

Satıcı yapılandırmasını başka neden bir dosyaya kaydetmeniz gerekir?

3) Aşağıdaki durumu göz önünde bulundurun. Standartta konfigürasyonun varlığının ilk aşamasında ihtiyacımız olan hiçbir işlevsellik olmadığını ve onu iyileştirmeye karar verildiğini varsayalım. İyileştirme minimum düzeydeydi, ancak gelecekte güncelleme sırasında yine de rahatsızlık yarattı. Ancak bir süre sonra, bu işlevselliğin (nesne sürümlemede olduğu gibi) standartta göründüğünü (ve çoğu zaman olduğu gibi, "el işi" iyileştirmesinden çok daha iyi uygulandığını) bulduk.

Tipik bir yapılandırmaya geri dönmeniz gerekebilecek gerçek durumlara birkaç örnek daha vereceğim:

1. Birkaç kez, yalnızca basılı formların düzenlerinin sonlandırıldığı yapılandırmalarla karşılaştım. Deneyim eksikliği veya cehalet nedeniyle, yapılandırmaya eşlik eden programcı, harici bir basılı form yapılandırmayı destekten kaldırdı ve yerleşik düzenleri sonlandırdı (genellikle bir şirket logosu eklemek için basmakalıp), ardından kullanıcılar bu fırsattan mahrum kaldı otomatik mod güncellemeler.

2. Yine, tipik işlevsellik konusundaki cehaletten (eski "yediler" genellikle bundan muzdariptir), özellikleri ve kategorileri kullanmak yerine, bunun iyi bir nedeni olmadığında dizinlerin / belgelerin ayrıntıları eklendi (örneğin veriler, yalnızca basılı formların çıktısı için kullanılır).

Elbette, güncellemelerin genellikle kritik olmadığı, ancak bu örnek değiştirilmiş SCP veya karmaşık otomasyonla ilgiliydi. Ve tam destekten çıkarmadan uygulanabilecek küçük iyileştirmeler nedeniyle, standart güncellemelerle kimsenin ihtiyaç duymadığı hemoroidlere sahibiz.

Yapılan iyileştirmelerden vazgeçmek ve konfigürasyonu tekrar tam desteğe almak için makul bir istek var. Nasıl yapılır?

Konfigürasyonu tekrar tam desteğe getirmenin tek yolu type.cf'yi yüklemektir (karşılaştırma ve birleştirme modunda değil, yani Konfigürasyonu dosyadan yükle öğesinde değil). Bunun için, sağlayıcı yapılandırmasını bir .cf dosyasına kaydetme yeteneğine ihtiyacımız var. Kaydediyoruz, sonra yüklüyoruz ve veritabanı yapılandırmasını güncelledikten sonra, orijinal biçiminde tipik bir yapılandırma elde ediyoruz, yani. kilitli :) Doğal olarak, bu eylemleri gerçekleştirmeden önce, standart yapılandırmaya döndükten sonra "yıkanacak" gerekli verileri önceden kaydetmeye / aktarmaya özen göstermelisiniz ve bunu yaptığınızdan emin olun. destek olmak Veri tabanı!

Bunlar, geliştiricinin cephaneliğinde olduğu ortaya çıkan basit olasılıklardır, ancak bu tekniklerin pratikte bilinmemesi, yukarıda açıklanan saatlerce gereksiz yaygaraya neden olabilir. Kim bilir - aferin ve kim bilmiyordu - hizmete alın ve zaman kazanın.