Cedar & Co., tek bir onaylı ihracat siparişini beklemek yerine stok yenileyerek, sabit bir tahminden 12 mağaza işletir. Her hafta biri Delta Garments'e bir yenileme siparişi verir, malları bir depoya alır, stoğu mağazalara taşır ve sonunda bir faturayı öder. Bu adımların her biri ticari veya finansal bir gerçek yaratır: sipariş edilen bir miktar, alınan bir miktar, bir stok bakiyesi, faturalanan bir tutar, ödenen bir tutar.
Bu gerçekler doğaları gereği ticari ve finansal oldukları için tek bir sistemde, genellikle ERP sisteminde, birlikte yaşamalıdır — bu, bu kursun önceki derslerde teknik spesifikasyonlardan ve görev durumundan ayırdığı aynı gerçek kategorisidir. Bu ders, yurt içi bir stoğa göre üretim programında bir satın alma siparişinin, bir envanter hareketinin, bir faturanın ve bir ödeme kaydının nerede kontrol edilmesi gerektiğini ve bunlardan herhangi birinin kontrolsüz bir e-tabloya kaymasına izin vermenin neden bu kursun daha önce uyardığı aynı sürüm çatışmalarını yarattığını gösterir.
İhtiyacınız olan: önceki derslerin ERP sistemi, PLM sistemi ve iş akışı aracının her birinin ne kontrol etmesi gerektiği ayrımı ve bir spesifikasyonun tek bir kontrollü eve ihtiyaç duyduğu fikri.
Bu dersin sonunda şunları yapabileceksiniz:
Burada kapsanmayan: muhasebe standartları, vergi kuralları veya belirli bir ERP ürününün finans modülünün yapılandırılması. Bu ders tedarikçiden bağımsız kalır ve iş kuralına odaklanır.
| Terim | Anlamı |
|---|---|
| Satın alma siparişi | Satın alınan mallar için onaylanan bir miktarı, fiyatı ve teslimat beklentisini kaydeden ticari bir belge. |
| Envanter hareketi | Alım, transfer veya satış gibi stok miktarında veya konumunda kaydedilen bir değişiklik. |
| Fatura | Teslim edilen mal veya hizmetler için borçlanılan tutarı kaydeden ticari bir belge. |
| Finansal kayıt | Bir ödeme veya tahakkuk eden bir yükümlülük gibi ticari bir olayı yansıtan muhasebe kayıtlarındaki bir giriş. |
| Açık hesap | Alıcının tedarikçiye, sevkiyat anında değil, faturalamadan sonra üzerinde anlaşılan bir süre içinde ödeme yaptığı bir ödeme düzenlemesi. |
| Mutabakat | Bir stok sayımı ve sistem bakiyesi gibi aynı gerçeğin iki kaydını karşılaştırarak uyuştuklarını doğrulamak. |
Her yenileme, alım, stok transferi, satış, fatura ve ödeme ticari veya finansal bir olaydır. Kurs 2'nin ilk dersi, bu gerçek kategorisinin ERP sisteminin temel işi olduğunu zaten ortaya koymuştu. Bir stoğa göre üretim programı bu kuralı değiştirmez; yalnızca aynı türde işlemin, onaylanan her ihracat siparişinde bir kez yerine sık sık, bazen haftalık olarak tekrarlandığı anlamına gelir.
Bir stok bakiyesi, ödenmemiş bir fatura tutarı veya bir ödeme vade tarihi her zaman ERP sisteminin güncel kaydından okunmalıdır. "Stokta olduğunu düşündüğümüz" veya "borçlu olduğumuzu düşündüğümüz" şeyi izleyen paralel bir e-tablo, tam olarak zaman içinde referans sisteminden sapan türden bir kolaylık kopyasıdır.
| Ne farklı olabilir | Karşılaşacağınız biçimler | Neden önemli |
|---|---|---|
| İhracat, siparişe göre üretim, akreditif | Sevkiyata yakın bir kez faturalanan, anlaşılan aşamada bir akreditif yoluyla ödenen tek bir onaylı sipariş. | Daha az ama daha büyük işlemler; her biri yine de kendi kontrollü satın alma siparişine, faturasına ve ödeme kaydına ihtiyaç duyar. |
| Yurt içi, stoğa göre üretim, açık hesap | Faturalamadan 60 gün sonra gibi anlaşılan koşullarda düzenli olarak faturalanan, sık yenileme siparişleri. | Daha sık işlemler, "takip etmek için" kontrolsüz bir e-tablonun sızma riskini artırır; bu tam olarak bu dersin uyardığı şeydir. |
| Birden çok mağazada tutulan stok | Envanter hareketleri, tedarikçiden alımlar ve müşterilere satışların yanı sıra mağazalar arası transferleri de içerir. | Alım, transfer veya satış olsun, her hareket yine de ERP sistemine ait bir ticari gerçektir. |
| Ticari zincirde bir acente veya ticaret şirketi | Bir ticaret şirketinin fabrikaya kendi satın alma siparişi ve bir perakendeciye kendi yeniden satış faturası, iki ayrı, bağlantılı ticari işlemdir. | Her tarafın kendi ERP sistemi kendi satın alma siparişlerini ve faturalarını kontrol eder; bir şirketin sistemi başka bir şirketin referans sistemi değildir. |
| Farklı ürün aileleri | Çorap ve triko, düz örme-hazır giyim, havlu ve ev tekstili yenileme siparişleri, farklı ürün alanlarıyla aynı satın alma siparişi, envanter ve fatura yapısını kullanır. | Ticari ve finansal kontrol ihtiyacı ürün aileleri arasında aynıdır; yalnızca her işlemdeki ürün detayı değişir. |
Cedar & Co., 12 mağazasını yurt içi stoğa göre üretim temelinde işletir ve Delta Garments'ten 60 gün açık hesap koşullarıyla satın alır. Bir mağaza müdürü stoğun azaldığını gördüğünde, bir telefon görüşmesi üzerinden gayriresmi olarak değil, ERP sisteminde bir yenileme siparişi verilir. Mallar depoya ulaştığında, aynı sistemde bir mal alımı kaydedilir ve stok bakiyesi güncellenir. Stok bir mağazaya taşındığında, bu hareket de kaydedilir. Delta Garments bir fatura düzenlediğinde, bu ERP sistemindeki alımla eşleştirilir ve ödeme vade tarihi, 60 günlük koşul altında fatura tarihinden izlenir.
Bunun yerine "sahip olduğumuzu düşündüğüm şey" konusunda kişisel bir defter tutan bir mağaza müdürü alternatif bir referans sistemi yaratmaz; bu defter, özellikle her biri bunu farklı şekilde yapan 12 mağaza genelinde, günler içinde ERP sisteminin bakiyesinden sapabilir.
Hesaplanan rakamİki sabit akademi işlemi, burada yalnızca referans rakamlar olarak kullanılan, Cedar & Co.'nun kendi siparişleri olarak değil, onaylı bir satın alma siparişinin ölçeğini gösterir. Sipariş A, parça başına 3,20 USD'den 15.000 tişörttür. Sipariş B kot pantolon, parça başına 9,80 USD'den 3.000 kot pantolondur.
Cedar & Co.'nun kendi yenileme siparişlerinden birinin gerçek boyutu ne olursa olsun, aynı ilke geçerlidir: satın alma siparişindeki onaylanan miktar ve fiyat, ERP sisteminde kontrol edilen ticari gerçeklerdir; bunu izleyen mal alımı ayrı bir envanter gerçeğidir ve onu izleyen fatura ayrı bir finansal gerçektir. ERP sistemi onaylı rakamları zaten tutarken, üçünden hiçbiri bir mağaza müdürünün hafızasından tahmin edilmemeli veya yeniden oluşturulmamalıdır.
Bir mağazadaki fiziksel bir stok sayımı ERP sisteminin kayıtlı bakiyesiyle eşleşmediğinde, sadece fiziksel sayıma güvenip sistemi ona uyacak şekilde ayarlamak cazip gelir. Ancak uyuşmazlığın kendisi yararlı bir bilgidir: kaydedilmemiş bir transferi, yanlış mağazaya girilmiş bir alımı veya hiç kaydedilmemiş bir satışı ortaya çıkarabilir. Boşluğu araştırmadan sistem bakiyesinin üzerine yazmak, altta yatan giriş hatasını düzeltmeden semptomu tedavi eder ve aynı uyuşmazlığın tekrarlanması muhtemeldir.
Her yenilemeyi, teslimatı, stok hareketini ve faturayı, mağaza ile fabrika arasında el değiştiren para ve mal olarak düşünün, ERP sistemini de bu değişikliklerin her birini kaydetmesi gereken tek ve güvenilir defter olarak düşünün. Bir mağaza müdürünün özel defteri veya "işleri sadece gözlemlemek için" bir kenarda tutulan bir e-tablo bu defterin yerini hiçbir zaman gerçekten alamaz; zamanla yalnızca ondan sessizce senkronizasyonunu kaybedebilir ve kimse bunu hemen fark etmeyebilir.
Bir stok sayımı sistemin söylediğiyle eşleşmediğinde, sistemi sadece sayımla uyacak şekilde değiştirmekle yetinmeyin. Önce neden uyuşmadıklarını dikkatle bulun, altta yatan gerçek nedeni düzeltin ve ancak ondan sonra sistemin herkesin yeniden güvenle baktığı tek cevap olmasına izin verin; aksi halde aynı uyuşmazlık başka bir mağazada tekrar ortaya çıkar.
Cedar & Co.'nun mağazalarından birinde, fiziksel bir stok sayımı, popüler bir tişört modelinden ERP sisteminin kayıtlı bakiyesinden 40 parça daha az olduğunu gösterir. Bir ekip üyesi, bir sonraki yenileme siparişi hesaplanmadan önce mağazanın kayıtları "doğru görünsün" diye sistem bakiyesinin hemen fiziksel sayıma uyacak şekilde aşağı ayarlanmasını önerir.
Sistem bakiyesi ayarlanmadan önce ne olmalıdır? Cevabı açmadan önce karar verin.
Neden olabilir bu yalnızca bu mağazayı etkilemeyebileceğinden, herhangi bir şeyi ayarlamadan önce fiziksel sayım ile sistem bakiyesi arasındaki boşluğu araştırın.
1. Bu model için son stok hareketlerini kontrol edin — gelen veya giden transferler, alımlar ve kaydedilen satışlar — eksik, yinelenen veya yanlış mağazaya uygulanmış görünen herhangi bir giriş için. 2. Başka bir mağazadan veya oraya bir transferin alınıp hiç kaydedilmediğini veya yanlış konuma kaydedildiğini kontrol edin. 3. Sisteme kaydedilmeden yapılan satışlar olup olmadığını kontrol edin, örneğin hemen girilmeyen manuel bir satış. 4. Yalnızca neden belirlendikten veya elenip elenmediği görüldükten sonra, sistem bakiyesini doğrulanan fiziksel sayımla eşleşecek şekilde ayarlayın ve ayarlamanın nedenini kaydedin.
Önce sistem bakiyesini ayarlayıp sonra araştırmak, eğer gerçekleşirse, bu veya başka bir mağazada aynı uyuşmazlığı üretmeye devam edecek gerçek bir süreç boşluğunu — kaydedilmemiş bir transfer veya satış — gizleme riski taşır.
Sipariş A'nın ve Sipariş B kot pantolonun onaylanan değerleri, tek bir onaylı ticari işlemin ölçeğini gösterir:
Bir mağazanın stok bakiyesi, 40 parçalık bir boşluğun gerçek nedeni bulunmadan sessizce ayarlanırsa, o bakiyeden hesaplanan bir sonraki yenileme siparişi aynı yönde yanlış olacak, ortaya çıkan fatura ve ödeme de öyle olacaktır. 12 mağaza genelinde tekrarlanan, araştırılmamış bir boşluk, altta yatan süreç hatası — kaçırılan bir transfer veya kaydedilmemiş bir satış — fark edilmeden devam ederken, stok ve ödeme yükümlülüklerini tek bir yenileme siparişinin değerinden çok daha fazla yanlış gösterebilir.
T17-C02 İşletme sistemi rol haritası çalışma kitabını kullanın. Bir yenileme programındaki her ticari veya finansal gerçek için, hangi sistemin onu kontrol ettiğini, bir uyuşmazlığın nasıl araştırılması gerektiğini ve yalnızca rakamı değil altta yatan nedeni düzeltmekten kimin sorumlu olduğunu kaydedin. Bildiğiniz bir yenileme döngüsüyle başlayın, ardından bunu Sipariş A ve Sipariş B kot pantolonla referans işlemler olarak karşılaştırın.
[İşletme sistemi rol haritası çalışma kitabını indirin](../../templates/T17-C02-business-system-role-map.xlsx)
1. Cedar & Co.'nun yurt içi stoğa göre üretim programında, bir mağaza için güncel stok bakiyesini hangi sistem kontrol etmelidir?
2. Fiziksel bir stok sayımı ERP sisteminin bakiyesinden düşüktür. İlk olarak ne olmalıdır?
3. Sipariş B kot pantolon için, 3.000 parça ve parça başına 9,80 USD'de, hangi rakam ERP sisteminin satın alma siparişi kaydına ait onaylı ticari gerçektir?
| TR | EN | AR | FR | Anlamı |
|---|---|---|---|---|
| Satın alma siparişi | Purchase order | أمر الشراء (طلبية الشراء) | Bon de commande | Bir alıcıdan miktarı, fiyatı ve teslimat tarihini onaylayan, alıcıyı sipariş ettiği malları ödemeye zorlayan bir belge. |
| Envanter hareketi | Inventory movement | حركة المخزون | Mouvement de stock | Alım, transfer veya satış gibi stok miktarında veya konumunda kaydedilen bir değişiklik. |
| Fatura | Invoice | الفاتورة | Facture | Teslim edilen mal veya hizmetler için borçlanılan tutarı kaydeden ticari bir belge. |
| Finansal kayıt | Financial posting | القيد المالي | Écriture comptable | Bir ödeme veya tahakkuk eden bir yükümlülük gibi ticari bir olayı yansıtan muhasebe kayıtlarındaki bir giriş. |
| Açık hesap | Open account | حساب مفتوح | Compte ouvert | Alıcının fabrikaya, teslimattan sonra üzerinde anlaşılan sayıda gün içinde, aralarında banka garantisi olmadan ödeme yaptığı bir ödeme yöntemi. |
| Mutabakat | Reconciliation | التسوية | Rapprochement | Bir stok sayımı ve sistem bakiyesi gibi aynı gerçeğin iki kaydını karşılaştırarak uyuştuklarını doğrulamak. |
Bir sonraki derste, bir tedarik acentesinin bir fabrikanın sistemleri ile bir alıcının sistemleri arasında yinelenen kayıt veya çelişen sürümler yaratmadan bilgiyi nasıl devrettiğini öğreneceksiniz. Kurs haritasına dön