1Özellikler
- Her parça için tek kanonik kayıt: LTC6909HMS#PBF ile ltc6909hms/pbf aynı parça
- Mühendisin konuştuğu gibi yazılan parametrik arama — “0402 100k”, “22uf 0805”, kelime sırası önemsiz
- Stok bir hareket defteri: bakiye saklanmıyor, hesaplanıyor; böylece her değişiklik geri alınabiliyor
- Kart dizimi: N kart dizilirse ne tükeneceğini önce gösteriyor, sonra kaydediyor, gerekirse geri alıyor
- İçerik parmak iziyle dosya envanteri — hangi BOM aktarıldı, hangisi değişti, hangisi kayboldu
- İçe aktarıcı hiçbir satırı atmıyor: çözemediğini sebebiyle birlikte inceleme kuyruğuna alıyor
- 204 otomatik test; her biri gerçek BOM dosyalarında yaşanmış bir tuzağı kilitliyor
2Teknik özellikler
- Dil
- Python 3.11
- Depolama
- SQLite · SQLAlchemy 2
- İçe aktarma
- .xlsx / .xls
- Arama
- Parça kodu + parametrik + bulanık
- Arayüz
- Masaüstü uygulama + komut satırı
- Test
- 204
3Şekil 1 — Parametrik arama
4Kullanımda
5Açıklama
Bir kart için alınan parçalar onlarca BOM dosyasına dağılıyor ve her dosya aynı parçayı biraz farklı yazıyor. BUL bu dosyaları tek bir kataloga okuyor; böylece günlük sorular — bunu daha önce aldık mı, kaç tane kaldı, yerine ne kullanabiliriz, hangi projede geçti — tek aramayla cevaplanıyor.
Sistem bir alım kayıtları listesi değil, katalog olarak kuruldu. Her üretici parça kodu tek bir normalize kayda düşüyor; alımlar, projeler ve distribütör kodları o kayda bağlanıyor. Değerler serbest metin açıklamalardan çıkarılıp SI birimlerinde saklanıyor, böylece “0402 100nF” yazıma değil kapasiteye ve kılıfa göre eşleşiyor ve tek sorguda parça kodu ile parametre karıştırılabiliyor.
Gerçek dosyalara ve tuzaklarına karşı yazıldı: Excel'in parça kodunu bilimsel gösterime çevirmesi ya da baştaki sıfırı atması, üretici BOM'larındaki 4K7 ve 13.3K yazımları, bir dosyada kart başına diğerinde sipariş adedi anlamına gelen adet sütunu, iki kez çarpılmış bir formül. Her tuzak tahmin edilmek yerine tespit edilip işaretleniyor ve her biri bir testle sabitlendi.