XML entegrasyonunda ürün ölçüsü ilk bakışta basit bir veri gibi görünebilir.

Örneğin tedarikçi:

30 cm

yazar.

Mağaza da:

30 cm

gösterir.

Ancak binlerce ürün ve birden fazla tedarikçi kullanılmaya başlandığında veri şu hale gelebilir:

Tedarikçi A:

30 cm

Tedarikçi B:

300 mm

Tedarikçi C:

0.30 m

Tedarikçi D:

30CM

Tedarikçi E:

30 santim

Bu değerler gerçekten aynı fiziksel uzunluğu ifade ediyorsa ortak bir sisteme dönüştürülebilir.

Fakat sorun yalnızca yazım farkı değildir.

Başka ürünlerde:

20x30x10 cm

500 gr

0.5 kg

1000 ml

1 L

6 Adet

1 Koli

12'li

gibi değerler gelebilir.

Bunların tamamı birim içeren veri gibi görünür.

Ancak anlattıkları şeyler farklıdır.

20 × 30 × 10 cm → fiziksel boyut

500 g → kütle

1 L → kapasite

6 adet → paket miktarı

1 koli → satış/paketleme birimi

Dolayısıyla xml ölçü birimi standardı oluştururken amaç yalnızca yazımdaki CM değerini cm yapmak değildir.

Asıl amaç:

hangi değerin hangi fiziksel veya ticari özelliği ifade ettiğini tanımlamak ve aynı anlama gelen değerleri ürün bilgisini bozmadan ortak veri yapısına dönüştürmektir.

Ulu İthalat'ın XML Bayilik sayfasında ürün adı, fiyat, stok, görseller ve benzeri ürün bilgilerinin XML aracılığıyla satış kanallarına aktarılabildiği belirtiliyor. Ürün veri alanları arttıkça ölçü ve teknik özelliklerin de tutarlı bir veri modelinde işlenmesi daha önemli hale gelir.

XML Ölçü ve Birim Standardı Nedir?

Pratik anlamıyla ölçü standardizasyonu:

kaynakta farklı biçimlerde ifade edilen aynı ölçü bilgisini ortak veri modeline dönüştürmek

olarak tanımlanabilir.

Örneğin:

Kaynak değer: 300 mm

Ölçü türü: uzunluk

Normalize değer: 300

Normalize birim: mm

Gösterim değeri: 30 cm

şeklinde tutulabilir.

Burada önemli olan:

kaynak değeri silmeden, hesaplama ve karşılaştırma için ortak bir değer oluşturmaktır.

1. Ölçü Değeri ile Birimi Ayrı Tutun

Kaynak XML:

30 cm

gönderiyor olabilir.

Bu tek metni sistemde sürekli:

"30 cm"

olarak tutmak yerine mümkünse iki parçaya ayrılabilir:

value = 30

unit = cm

Böylece:

• filtreleme,
• sıralama,
• karşılaştırma,
• dönüşüm

çok daha kontrollü yapılabilir.

2. Ölçünün Türünü de Ayrıca Kaydedin

Sadece:

value = 30

unit = cm

yeterli olmayabilir.

Bu 30 cm:

• genişlik mi,
• yükseklik mi,
• derinlik mi,
• çap mı,
• uzunluk mu?

bilinmelidir.

Daha iyi veri modeli:

dimension_type = width

value = 30

unit = cm

gibi olabilir.

3. Tek Bir measure Alanına Her Şeyi Doldurmayın

Örneğin:

measure = 20x30x40cm

işlenebilir ancak yapılandırılmış veri açısından zayıftır.

Daha kontrollü yapı:

width = 20

height = 30

depth = 40

dimension_unit = cm

olabilir.

Ancak bunun için kaynak değerlerin sırası kesin olarak bilinmelidir.

4. 20x30x40 İfadesinin Sırasını Tahmin Etmeyin

Tedarikçi:

20x30x40 cm

yazıyor.

Bu:

en × boy × yükseklik

olabilir.

Başka tedarikçide:

genişlik × derinlik × yükseklik

olabilir.

Başka kaynak:

uzunluk × genişlik × yükseklik

kullanabilir.

Dokümantasyon olmadan:

ilk sayı kesin genişliktir

varsayımı yapılmamalıdır.

5. Ölçü Sırasını Tedarikçi Bazında Tanımlayın

Örneğin:

Tedarikçi A

dimension = width × height × depth

Tedarikçi B

dimension = length × width × height

kullanıyor olabilir.

Bu nedenle parser:

tedarikçi + alan

bağlamında çalışmalıdır.

6. Tek Boyutlu ve Çok Boyutlu Ölçüyü Ayırın

Örneğin kablo:

2 m

uzunluğa sahip olabilir.

Kutu:

20 × 30 × 10 cm

ölçülerine sahip olabilir.

Bunları aynı veri modeline zorla sokmak gereksiz olabilir.

Örneğin:

length

ve:

package_dimensions

ayrı özellik grupları olabilir.

7. Ürün Ölçüsü ile Paket Ölçüsünü Birbirine Karıştırmayın

Bir ürünün fiziksel ölçüsü:

20 × 30 × 10 cm

olabilir.

Kargo kutusu:

25 × 35 × 15 cm

olabilir.

Bu iki bilgi farklı amaçlara hizmet eder.

Biri müşterinin ürün seçimini,

diğeri lojistik ve kargoyu

etkileyebilir.

8. Product Dimensions ve Shipping Dimensions Ayrı Alanlarda Tutulabilir

Örneğin:

product_width

product_height

product_depth

ve ayrı:

package_width

package_height

package_depth

alanları bulunabilir.

Bu ayrım kargo hesaplamalarında yanlış ürün ölçüsünün kullanılmasını önleyebilir.

9. Net Ağırlık ve Brüt Ağırlığı Ayırın

Örneğin ürün:

450 g

paketli halde:

620 g

olabilir.

İlk değer:

net weight

ikinci:

gross/shipping weight

olarak düşünülebilir.

Tek weight alanı her iki anlamda kullanılırsa sistemin hangi ağırlığı kullandığı belirsizleşir.

10. “Ağırlık” ile “Kütle” Teknik Ayrımını Ürün Veri Modelinde Gereksiz Karmaşıklaştırmayın

SI sisteminde kilogram kütle birimidir. BIPM, kilogramı kg sembolüyle SI temel kütle birimi olarak tanımlar.

E-ticaret tarafında ise ürün panellerinde genellikle “ağırlık” ifadesi kullanılır.

Veri modelinde esas amaç:

hangi değerin ürünün net kütlesi, hangisinin paket/kargo değeri olduğunu

netleştirmektir.

11. Uzunluk İçin Bir Canonical Birim Seçebilirsiniz

Örneğin iç sistem bütün uzunlukları:

mm

olarak saklayabilir.

Kaynak:

30 cm

↓

Canonical:

300 mm

olabilir.

Başka işletme canonical olarak:

cm

kullanabilir.

Tek bir evrensel e-ticaret tercihi yoktur.

Önemli olan bütün aynı tür değerlerin aynı iç standarda dönüşmesidir.

12. Metre, Santimetre ve Milimetre Dönüşümü Standarttır

BIPM'nin SI önek sisteminde:

centi = 10⁻²

milli = 10⁻³

olarak tanımlanır. Metre de SI uzunluk birimidir.

Dolayısıyla:

1 m = 100 cm = 1000 mm

ilişkisi nettir.

Ancak dönüşüm matematiksel olarak mümkün diye her XML alanı otomatik dönüştürülmemelidir; önce değerin gerçekten uzunluk ifade ettiği doğrulanmalıdır.

13. m Sembolünü Alan Bağlamından Kopuk Yorumlamayın

XML alanında:

M

değeri görülebilir.

Bu:

Medium beden

olabilir.

Başka alanda:

m

metre

anlamına gelebilir.

Dolayısıyla bütün:

M → metre

veya:

m → metre

dönüşümleri güvenli değildir.

Alan bağlamı zorunludur.

14. Birim Sembollerinde Büyük-Küçük Harf Önemlidir

BIPM'nin güncel SI rehberi birim ve önek sembollerinin belirli yazım kurallarına sahip olduğunu açıklıyor; örneğin kilo önekinin sembolü k, milli önekinin sembolü m olarak kullanılıyor.

Bu nedenle canonical sistem:

CM

Cm

cm

değerleri gerçekten santimetreyi ifade ettiği doğrulanmışsa:

cm

biçimine dönüştürebilir.

15. Kullanıcıya Gösterilen Birim ile İç Birim Aynı Olmak Zorunda Değildir

İç sistem:

300 mm

saklayabilir.

Müşteriye:

30 cm

gösterebilir.

Burada:

storage unit

ve:

display unit

ayrı tutulabilir.

Bu, özellikle farklı ürün büyüklüklerinde daha okunabilir gösterim sağlar.

16. Çok Küçük Ürünlerde Milimetre Daha Kullanışlı Olabilir

Örneğin:

vida kalınlığı,

küçük bağlantı parçası,

elektronik komponent ölçüsü

gibi değerlerde mm daha doğal olabilir.

Bu durumda:

0,3 cm

yerine:

3 mm

gösterimi tercih edilebilir.

Ancak bu bir XML zorunluluğu değil ürün veri sunum kuralıdır.

17. Büyük Ürünlerde Metre veya Santimetre Tercih Edilebilir

Örneğin:

2000 mm

doğru bir değerdir.

Ancak müşteriye:

200 cm

veya:

2 m

göstermek daha anlaşılır olabilir.

İç sistemin canonical birimi değişmeden kalabilir.

18. Ölçü Birimi Dönüşümü Değeri Değiştirmemelidir

Örneğin:

30 cm

↓

300 mm

aynı fiziksel uzunluğu ifade eder.

Ama:

30 cm → 30 mm

dönüşümü bir normalizasyon değil veri hatasıdır.

Dönüşümden sonra fiziksel eşdeğerlik test edilmelidir.

19. Dönüşüm Formüllerini Tek Bir Merkezi Sistemde Tutun

Bir yerde:

cm → mm

başka yerde:

ürün başlığında ayrı dönüşüm,

pazaryerinde üçüncü dönüşüm

kullanılırsa farklı sonuçlar ortaya çıkabilir.

Daha kontrollü sistem:

tek conversion layer

üzerinden çalışabilir.

20. Aynı Ölçüyü Tekrar Tekrar Dönüştürmeyin

Örneğin:

Kaynak:

30 cm.

İlk sync:

300 mm.

Sonraki sync yanlışlıkla mevcut 300 değerini yeniden:

300 cm → 3000 mm

olarak yorumlamamalıdır.

Her dönüşüm mümkünse ham kaynak değerden veya kesin normalized değerden yapılmalıdır.

21. Ham Kaynak Ölçüsünü Saklayın

Örneğin:

raw_measurement = "30 CM"

normalized_value = 300

normalized_unit = mm

şeklinde tutulabilir.

Daha sonra yanlış dönüşüm şüphesi çıktığında:

Tedarikçi aslında ne göndermişti?

sorusuna cevap verilebilir.

22. Ölçü Normalizasyonunu İdempotent Hale Getirin

Aynı:

30 cm

değeri bugün işlendiğinde:

300 mm

yarın tekrar işlendiğinde:

300 mm

olarak kalmalıdır.

Her çalışmada değer büyüyor veya küçülüyorsa dönüşüm zincirinde hata vardır.

23. Ondalık Ayırıcısını Ölçü Dönüşümünden Önce Çözün

Kaynak:

12,5 cm

gönderebilir.

Başka kaynak:

12.5 cm

gönderebilir.

İki değer aynı anlamı taşıyabilir.

Önce yerel sayı formatı doğru parse edilmeli.

Sonra birim dönüşümü yapılmalıdır.

24. Binlik Ayırıcıyla Ondalık Ayırıcıyı Karıştırmayın

Örneğin:

1.250 mm

Türkçe yazım bağlamında:

1250 mm

anlamına gelebilir.

Başka veri formatında nokta ondalık işareti olarak kullanılabilir.

Kaynak formatı bilinmeden:

noktaları sil

kuralı kullanılmamalıdır.

25. Ölçü Metninden Sayı Çıkarırken Birimi Kaybetmeyin

Riskli işlem:

30 cm

↓

30

Sonrasında sistem:

30 ne?

sorusuna cevap veremez.

Bu nedenle sayı ve birim birlikte parse edilmelidir.

26. Birimsiz Ölçüyü Otomatik Santimetre Kabul Etmeyin

Kaynak:

width=30

gönderiyor.

Bu:

• 30 mm,
• 30 cm,
• 30 m

olabilir.

Tedarikçi dokümantasyonunda alanın birimi tanımlanmamışsa tahmin yapılmamalıdır.

Kayıt:

UNIT_UNKNOWN

olarak işaretlenebilir.

27. Birim Alanı Ayrı Geliyorsa İkisini Birlikte Okuyun

Örneğin:

width=30

unit=cm

şeklinde iki alan bulunabilir.

Entegrasyon yalnızca width değerini almamalıdır.

Değer:

30 + cm

olarak değerlendirilmelidir.

28. Bir Alan Milimetre, Diğeri Santimetre Kullanabilir

Örneğin:

product_width=300

product_unit=mm

ama:

package_width=35

package_unit=cm

olabilir.

Tek global unit varsayımı kullanılmamalıdır.

29. Kütle İçin Gram ve Kilogramı Ortaklaştırın

Örneğin:

500 g

ve:

0,5 kg

aynı kütleyi ifade edebilir.

Canonical model örneğin:

500 g

tutabilir.

Başka sistem:

0,5 kg

tutabilir.

Önemli olan hesaplamalarda birbiriyle karşılaştırılabilir tek standardın kullanılmasıdır.

30. Kilogramın Sembolü kg Olarak Korunmalıdır

BIPM kilogramın sembolünü kg olarak tanımlar.

Kaynak:

KG

Kg

kilo

gönderiyorsa ve gerçekten kilogramı ifade ettiği doğrulanmışsa canonical değer:

kg

olarak kullanılabilir.

31. gr ve g Değerlerini Kontrollü Eşleştirin

Ticari XML'lerde gram için:

gr

kullanılması sık görülebilir.

SI birim sembolü ise:

g

şeklindedir.

Kaynak değerin gram anlamına geldiği doğrulanırsa:

gr

↓

g

canonical mapping'i yapılabilir.

Ancak ham değer yine saklanabilir.

32. Kapasite ile Ürün Dış Hacmini Ayırın

Örneğin bir saklama kabı:

1 L kapasite

taşıyor olabilir.

Dış ölçüsü:

15 × 10 × 8 cm

olabilir.

Bu iki bilgi birbirinden farklıdır.

Capacity

ve:

dimensions

ayrı alanlardır.

33. Litre ve Mililitre İçin Ortak Sistem Kurabilirsiniz

Örneğin:

1 L

1000 mL

aynı kapasiteyi ifade edebilir.

BIPM litreyi SI olmayan ancak SI ile kullanımına izin verilen birim olarak listeler ve hem l hem L sembolünün kullanılabileceğini belirtir.

Mağazanız kendi canonical gösteriminde örneğin:

L / mL

kullanmayı seçebilir.

Önemli olan bütün katalogda aynı yazım politikasının korunmasıdır.

34. ml, ML, mL İçin Tek Canonical Gösterim Seçebilirsiniz

Kaynaklar farklı yazabilir.

Sistem örneğin:

mL

biçimini seçebilir.

Böylece:

500ml

500 ML

500 mL

tek:

500 mL

gösterimine dönüşür.

35. Kapasiteyi Ürün Adından Tahmin Etmeyin

Ürün adı:

Büyük Boy Sürahi

olabilir.

Buradan:

2 L

kapasite uydurulamaz.

Normalizasyon yalnızca mevcut veriyi standardize eder.

Eksik teknik bilgiyi icat etmez.

36. Alan Adının volume Olması Bile Bağlam Gerektirebilir

Bir sistemde:

volume

ürünün kapasitesi olabilir.

Başka sistemde:

kargo hacmi

anlamına gelebilir.

Alan sözlüğü olmadan aynı etiketi farklı tedarikçilerde aynı şekilde yorumlamak risklidir.

37. Ürün Ölçüsü ile Kargo Desisini Aynı Veri Saymayın

Ürün:

20 × 20 × 20 cm

olabilir.

Kargo paketi daha büyük olabilir.

Ayrıca kargo firmalarının hacimsel ağırlık/desi kuralları ticari hesaplama kurallarıdır.

118 fiziksel ölçü veri standardını sahiplenmeli; kargo ücret formülüne dönüşmemelidir.

38. Ölçülerden Otomatik Desi Üretmeden Önce Kullanılan Ölçünün Paket Ölçüsü Olduğunu Doğrulayın

Ürün ölçüsü üzerinden kargo hesabı yapılırsa:

ambalaj,

koruyucu malzeme,

kutu

hesaba katılmayabilir.

Bu nedenle lojistik hesaplamalarda:

package_dimensions

tercih edilmesi gerekebilir.

39. Satış Birimini Fiziksel Ölçü Birimlerinden Ayırın

Bu 118'in en önemli özgün noktalarından biridir.

Aşağıdaki değerlerin tamamı “birim” değildir:

cm → uzunluk birimi

kg → kütle birimi

L → kapasite birimi

adet → satış/miktar birimi

set → ürün sunum biçimi

koli → paketleme/satış birimi

Dolayısıyla tek:

unit

alanında tutulmaları veri modelini karıştırabilir.

40. 6 adet Bilgisini Santimetre Benzeri Bir Measurement Olarak Tutmayın

Örneğin:

package_quantity = 6

sale_unit = piece

şeklinde yapılandırılabilir.

Bu bilgi:

length/value/unit

modelinden farklıdır.

41. Set Miktarını da Ayrı Tutun

Örneğin:

6'lı kaşık seti

için:

package_quantity = 6

sale_unit = set

gibi bir yapı gerekebilir.

Buradaki “6”, fiziksel ölçü değildir.

42. Koli İçeriği ile Satış Adedini Ayırın

XML:

Koli İçi: 24

gönderebilir.

Ama ürün mağazada:

tekli

satılıyor olabilir.

Dolayısıyla:

carton_quantity = 24

demek:

müşteri 24 adet almak zorunda

demek değildir.

Satış kuralı ayrıca doğrulanmalıdır.

43. Koli Stoğu ile Adet Stoğunu Ölçü/Birim Normalizasyonuyla Yanlış Dönüştürmeyin

Tedarikçi:

stok = 10

unit = koli

gönderiyor.

Her koli:

24 adet.

Teorik toplam:

240 adet

olabilir.

Ancak tedarikçinin koliyi bölerek tekli satışa izin verip vermediği bilinmeden:

stok = 240

yapmak doğru olmayabilir.

Bu fiziksel dönüşüm değil ticari satış kuralıdır.

44. Ürün Ölçüsünün Varyant Oluşturup Oluşturmadığını Belirleyin

Örneğin:

Organizer 20 cm

Organizer 30 cm

iki ayrı varyant olabilir.

Ancak:

ürün yüksekliği 20 cm

yalnızca teknik özellik de olabilir.

Ölçünün:

variant-defining attribute

olup olmadığı ürün tipine göre belirlenmelidir.

45. Varyant Ölçülerini Aynı Ürün İçinde Birbirine Karıştırmayın

Örneğin:

20 cm SKU → A

30 cm SKU → B

40 cm SKU → C

Her biri ayrı stok ve fiyat taşıyorsa normalize ölçü SKU seviyesinde korunmalıdır.

Parent ürüne tek:

30 cm

değeri yazmak diğer varyantları yanlış tanımlar.

46. Ölçü Eşleştirmesini Ürün Kimliği İçin Yardımcı Sinyal Olarak Kullanabilirsiniz

İki ürün:

aynı marka,

aynı model,

aynı barkod benzerliği

taşıyor.

Ancak biri:

20 cm

diğeri:

30 cm.

Bu fark iki ayrı satılabilir ürün olduklarını gösterebilir.

Bu nedenle ölçü verisinin standardize edilmesi supplier-to-catalog eşleştirmesini de güçlendirebilir.

47. Fakat Aynı Ölçü İki Ürünün Aynı Olduğunu Kanıtlamaz

İki farklı ürün:

30 cm

olabilir.

Dolayısıyla ölçü:

identity evidence

olarak yardımcı olabilir ama tek başına ürün kimliği değildir.

48. Nominal Ölçülerde Otomatik Matematiksel Dönüşüme Dikkat Edin

Bazı teknik ürünlerde yazılan ölçü doğrudan fiziksel cetvel ölçüsü olmayabilir.

Örneğin:

• bağlantı parçaları,
• vida ölçüleri,
• diş ölçüleri,
• sektör standardı nominal ölçüler

özel anlam taşıyabilir.

Bu nedenle:

ölçüde bir sayı ve birim gördüm → kesin geometrik dönüşüm yap

yaklaşımı her kategoride güvenli değildir.

49. Özellikle İnç Tabanlı Teknik Ölçülerde Ürün Semantiğini Koruyun

Bir teknik üründe:

1/2"

ifadesi ürünün standart/nominal bağlantı ölçüsü olabilir.

Bunu kullanıcıya sadece:

12,7 mm

şeklinde dönüştürmek ürünün ticari tanımını bozabilir.

Matematiksel dönüşüm mümkün olsa bile ürünün standart adı ayrıca korunmalıdır.

50. Orijinal Teknik Birimi Göstermek Bazı Kategorilerde Daha Doğru Olabilir

Örneğin belirli:

• hırdavat,
• tesisat,
• bağlantı,
• elektronik

ürünleri piyasada geleneksel birimle tanınıyor olabilir.

Sistem karşılaştırma için canonical ölçü tutarken müşteriye:

kaynak/standart endüstri ölçüsünü

gösterebilir.

51. Ölçüyü Başlıktan Otomatik Çıkarırken Güven Seviyesi Kullanın

Başlık:

Organizer 30 CM

ise 30 cm ölçü olabilir.

Başlık:

Model 30 CMX

ise 30 model kodunun parçası olabilir.

Dolayısıyla başlık parsing:

kesin veri kaynağı

olarak görülmemelidir.

52. Yapılandırılmış XML Alanını Ürün Başlığına Tercih Edin

Örneğin:

<width>30</width>

<width_unit>cm</width_unit>

bulunuyorsa bu veri:

ürün adındaki:

30 CM

ifadesine göre daha kolay işlenebilir.

Ancak yine de tedarikçinin alan anlamı doğrulanmalıdır.

53. Ürün Açıklamasından Ölçü Çıkarma Daha Düşük Güvenli Bir İşlem Olmalıdır

Açıklamada:

“yaklaşık 30 cm alan için uygundur”

ifadesi geçebilir.

Bu:

ürünün kendisi 30 cm

demek değildir.

Dolayısıyla açıklama metninden otomatik technical attribute oluşturmak yanlış veri üretebilir.

54. “Yaklaşık” Ölçülerde Kesinlik Bilgisini Kaybetmeyin

Kaynak:

yaklaşık 30 cm

diyorsa normalize sistem bunu:

tam olarak 300 mm

gibi kesinlik iddiasıyla sunmamalıdır.

Örneğin ayrıca:

measurement_precision = approximate

bilgisi korunabilir.

55. Aralık Ölçülerini Tek Sayıya Dönüştürmeyin

Örneğin:

20–30 cm

değeri:

25 cm

yapılmamalıdır.

Bu bir aralıktır.

Daha doğru veri modeli:

min = 20

max = 30

unit = cm

olabilir.

56. Ayarlanabilir Ürünlerde Minimum ve Maksimum Ölçüleri Ayırın

Örneğin teleskopik ürün:

60–100 cm

olabilir.

Tek:

length = 80

değeri gerçeği yanlış temsil eder.

min_length

ve:

max_length

alanları daha uygundur.

57. Çap, Kalınlık ve Uzunluğu Aynı Alan Yapmayın

Örneğin boru:

çap = 20 mm

uzunluk = 2 m

taşıyabilir.

İkisi de uzunluk birimi kullanır.

Ancak anlattıkları fiziksel özellik farklıdır.

Yani:

aynı unit ≠ aynı attribute.

58. Ölçü Türü Sözlüğü Oluşturun

Örneğin:

length

width

height

depth

diameter

thickness

weight

capacity

package_quantity

gibi canonical attribute adları tanımlanabilir.

Kaynak:

en

genislik

width

değerleri doğrulandıktan sonra:

width

alanına eşleştirilebilir.

59. Birim Sözlüğü de Ayrı Oluşturun

Örneğin kaynak alias'ları:

CM

cm.

santim

↓

cm

KG

Kg

kilo

↓

kg

ML

ml

↓

seçtiğiniz canonical biçim.

Bu sözlük yalnızca doğrulanmış eş anlamlı yazımlar için kullanılmalıdır.

60. Bilinmeyen Birimi En Yakın Birime Zorla Eşleştirmeyin

Kaynak:

unit = "boy"

gönderiyor.

Sistem bunu:

cm

sanmamalıdır.

Sonuç:

UNKNOWN_UNIT

olarak inceleme kuyruğuna gönderilebilir.

61. Unit Conversion ile Unit Mapping'i Ayırın

Mapping

CM → cm

Değer değişmez.

Conversion

30 cm → 300 mm

Değer de değişir.

Bu iki işlem ayrı tutulursa hata araştırması kolaylaşır.

62. Dönüşüm Sonucunda Kaynakla Eşdeğerlik Testi Yapın

Örneğin:

30 cm → 300 mm.

Geri dönüşüm:

300 mm → 30 cm.

Sonuç kaynak değerle aynı olmalıdır.

Otomatik testlerde bu tür round-trip kontroller kullanılabilir.

63. Çok Fazla Ondalık Üretmeyin

Örneğin dönüşüm sonrası:

29.9999999997 cm

gibi floating-point sonucu görülebilir.

Ürün verisinde gerekli hassasiyet belirlenmeli ve kontrollü decimal hesap kullanılmalıdır.

Ancak ölçü yuvarlaması gerçek ürün bilgisini değiştirmemelidir.

64. Ölçü Hassasiyetini Ürün Tipine Göre Belirleyin

Mobilya:

120,0 cm

gibi bir hassasiyet yeterli olabilir.

Küçük teknik parçada:

2,35 mm

gerekebilir.

Bütün ürünlere:

iki ondalık

veya:

tam sayı

zorlamak doğru olmayabilir.

65. Kaynakta Bulunan Hassasiyeti Gereksiz Yere Kaybetmeyin

Kaynak:

12,75 mm

gönderiyor.

Canonical sistem:

13 mm

yapıyorsa ürün özelliği değişmiş olabilir.

Özellikle teknik ürünlerde ölçü yuvarlama dikkatli kullanılmalıdır.

66. Ölçü Formatını Kullanıcı Arayüzünde Tutarlı Gösterin

Aynı kategori içinde:

30CM

30 cm

30 Santim

300mm

gibi karışık görüntüler profesyonel olmayan katalog görünümü oluşturabilir.

Canonical display kuralı bunu:

30 cm

gibi tek biçimde gösterebilir.

67. Sayı ile Birim Arasındaki Yazımı Standardize Edin

BIPM SI yazım rehberinde sayı ve birim sembolü ayrı nicelik bileşenleri olarak ele alınır ve standart birim sembolleri belirlenmiştir.

E-ticaret veri sunumunda örneğin:

30cm

yerine:

30 cm

gibi tek bir display standardı kullanılabilir.

68. Birim Standardını Ürün Adına Körü Körüne Uygulamayın

Ürün adı marka veya model içerebilir:

X30CM Pro

gibi.

Global:

30CM → 30 cm

text replacement işlemi model adını bozabilir.

Yapılandırılmış attribute alanları ile serbest metin ayrı işlenmelidir.

69. Açıklama İçindeki Birimleri Otomatik Toplu Değiştirmeden Önce Bağlamı Kontrol Edin

Açıklamada:

M beden

M10 vida

30 cm

gibi birbirinden farklı değerler olabilir.

Regex ile bütün M harflerini metreye çevirmek ciddi veri bozukluğu oluşturur.

70. Ölçü Standardını Kategori Bazında Özelleştirin

Örneğin:

Mobilya

genişlik + yükseklik + derinlik

Şişe / kap

kapasite

Hırdavat

uzunluk + çap + kalınlık

Tekstil

beden + ürün ölçüsü

Elektronik

boyut + ağırlık + teknik kapasite

gibi farklı attribute şemaları kullanılabilir.

71. Her Ürüne Her Ölçü Alanını Zorunlu Yapmayın

Bir cezvede:

kapasite önemli olabilir.

Bir tornavidada:

uzunluk önemli olabilir.

Bir organizerda:

en × boy × yükseklik önemli olabilir.

Dolayısıyla:

bütün ürünlerde width + height + depth + weight + capacity zorunlu

kuralı gereksizdir.

72. Zorunlu Ölçü Alanlarını Kategori Matrisiyle Belirleyin

Örneğin işletme:

Mobilya → en/boy/yükseklik gerekli

Kapasiteli mutfak ürünü → kapasite gerekli

Set ürün → paket miktarı gerekli

gibi kurallar kullanabilir.

114 numaralı zorunlu alan rehberi bu required-field yaklaşımının genel tarafını sahiplenir.

118 ise ölçü alanlarının kendisinin nasıl standardize edileceğini anlatmalıdır.

73. Ölçü Verisi Eksikse Tahmin Üretmeyin

Ürün fotoğrafından:

yaklaşık 25 cm

görünüyor diye XML'e:

25 cm

eklenmemelidir.

Ölçü bilgisi:

• tedarikçiden,
• üretici bilgisinden,
• doğrulanmış fiziksel ölçümden

gelmelidir.

74. Çelişkili Ölçüleri Otomatik Birleştirmeyin

XML:

30 cm

üretici verisi:

32 cm

diyor olabilir.

Bu durumda:

ortalama 31 cm

oluşturulmamalıdır.

Kayıt:

MEASUREMENT_CONFLICT

olarak incelemeye alınabilir.

75. Birden Fazla Tedarikçiden Gelen Ölçüyü Kaynak Bazında Saklayın

Supplier A:

30 cm.

Supplier B:

32 cm.

Mağaza canonical:

henüz doğrulanmadı.

Bu durumda her iki kaynak ayrı tutulabilir.

Doğru bilgi belirlendikten sonra canonical değer atanabilir.

76. Ölçü Değişikliğini Normal Fiyat Değişikliği Gibi Görmeyin

Fiyatın sık değişmesi normal olabilir.

Ama ürün:

30 cm → 45 cm

olduysa bu:

• veri hatası,
• model değişimi,
• yanlış eşleşme,
• farklı varyant

olabilir.

Ölçü değişiklikleri özellikle ürün kimliği açısından daha yüksek riskli sinyal olarak değerlendirilebilir.

77. Büyük Ölçü Değişikliklerinde Manuel Kontrol Kullanılabilir

Örneğin:

width:

30 → 300 cm.

Bu gerçek olabilir.

Ancak muhtemel:

mm/cm birim karışıklığı

da olabilir.

Bu yüzden anormal ölçü değişiklikleri:

REVIEW_REQUIRED

durumuna alınabilir.

78. Birim Değiştiğinde Sayının da Doğru Dönüştüğünü Kontrol Edin

Kaynak dün:

30 cm

bugün:

300 mm

gönderiyor.

Ürün fiziksel olarak değişmemiştir.

Sistem yalnızca ham sayı:

30 → 300

değişti diye:

ölçü 10 kat arttı

alarmı vermemelidir.

Karşılaştırma normalized değer üzerinden yapılmalıdır.

79. Değişiklik Kontrolünü Canonical Birimde Yapın

Örneğin:

Dün:

30 cm → 300 mm canonical.

Bugün:

300 mm → 300 mm canonical.

Sonuç:

ölçü değişmedi.

Bu, normalizasyonun en önemli faydalarından biridir.

80. Ölçü Dönüşümlerini Loglayın

Örneğin:

Supplier: A

SKU: ABC125

Field: width

Raw: 30

Raw unit: cm

Normalized: 300

Normalized unit: mm

Rule: CM_TO_MM

şeklinde log tutulabilir.

XML ÖLÇÜ VE BİRİM STANDARDI İÇİN PRATİK KONTROL LİSTESİ

Ölçü türü

Değerin uzunluk, genişlik, yükseklik, çap, ağırlık veya kapasite olduğu biliniyor mu?

Kaynak değer

Orijinal XML değeri korunuyor mu?

Kaynak birim

Tedarikçinin kullandığı birim biliniyor mu?

Canonical değer

Ortak hesaplama değeri var mı?

Canonical birim

Aynı tür ölçüler tek birimde tutuluyor mu?

Gösterim birimi

Kullanıcıya hangi birimin gösterileceği belli mi?

Ürün/paket ölçüsü

İkisi ayrılıyor mu?

Net/brüt ağırlık

Ayrı tutuluyor mu?

Kapasite

Dış hacimden ayrılıyor mu?

Satış birimi

Adet, set ve koli fiziksel ölçüden ayrılıyor mu?

Paket miktarı

Koli içi veya set adedi yapılandırılmış mı?

Varyant

Ölçü varyantı doğru SKU'ya bağlı mı?

Sıra

20×30×40 değerlerinin hangi eksenleri temsil ettiği biliniyor mu?

Ondalık

Virgül ve nokta doğru parse ediliyor mu?

Birim alias

CM, cm, santim gibi değerler kontrollü eşleşiyor mu?

Bilinmeyen birim

Zorla eşleştirilmek yerine incelemeye mi gidiyor?

Nominal ölçü

Teknik ürünlerde gerçek fiziksel ölçüyle karıştırılıyor mu?

Aralık

20–30 cm tek sayıya indirgeniyor mu?

Yaklaşık değer

Kesin değer gibi sunuluyor mu?

Hassasiyet

Gereksiz yuvarlama yapılıyor mu?

Çelişkili veri

İki kaynak farklı ölçü verirse alarm oluşuyor mu?

Değişiklik

30 cm → 300 mm değişiklik sanılıyor mu?

Log

Hangi dönüşüm kuralının uygulandığı görülebiliyor mu?

Test

Dönüşüm ve geri dönüş testleri yapılıyor mu?

XML ÖLÇÜ VE BİRİM STANDARDI NASIL KURULUR?

Pratik uygulama şu sırayla kurulabilir:

1. XML'deki bütün ölçü ve birim alanlarını çıkarın.

2. Her alanın neyi ölçtüğünü tedarikçi dokümantasyonundan doğrulayın.

3. Fiziksel ölçü ile paket/satış birimlerini ayırın.

4. Uzunluk, kütle, kapasite ve adet gibi veri türlerini sınıflandırın.

5. Width, height, depth, diameter, weight ve capacity gibi canonical alanları belirleyin.

6. Her ölçü türü için canonical iç birim seçin.

7. Kaynak birim alias sözlüğü oluşturun.

8. Kaynak sayı formatlarını normalize edin.

9. Değer ve birimi ayrı alanlara ayırın.

10. Birim dönüşümlerini merkezi dönüşüm katmanında uygulayın.

11. Ham kaynak değerlerini değiştirmeden saklayın.

12. Ürün ve paket ölçülerini ayrı tutun.

13. Net/brüt ağırlık ve kapasite gibi farklı kavramları ayırın.

14. Set, adet ve koli bilgilerini measurement alanından çıkarın.

15. Varyant ölçülerini SKU seviyesinde yönetin.

16. Bilinmeyen veya nominal teknik ölçüleri otomatik çevirmeyin.

17. Çelişkili ve olağan dışı ölçü değişikliklerini review kuyruğuna gönderin.

18. 50–100 farklı ürün üzerinde raw → normalized karşılaştırması yapın.

19. Dönüşüm kurallarını ve eski/yeni değerleri loglayın.

20. Sonuçlar doğruysa canonical ölçü modelini bütün XML kataloğunda kademeli uygulayın.

SIK SORULAN SORULAR

XML'deki bütün ölçüleri santimetreye çevirmek doğru mudur?

Her zaman değil. Santimetre birçok tüketici ürününde kullanışlı olabilir ancak küçük teknik ürünlerde milimetre, büyük ürünlerde metre veya ürünün sektörel olarak tanındığı başka bir gösterim daha uygun olabilir. Esas amaç bütün aynı tür verileri karşılaştırılabilir bir canonical sisteme dönüştürmektir.

30 cm ile 300 mm aynı ürün ölçüsü olarak değerlendirilebilir mi?

Değer gerçekten aynı fiziksel özelliği ifade ediyorsa evet. SI önek ilişkilerine göre 30 cm, 300 mm'ye eşittir. Ancak birinin ürün genişliği, diğerinin paket yüksekliği olması durumunda aynı alan olarak birleştirilmemelidir.

20x30x40 cm değeri otomatik olarak en × boy × yükseklik şeklinde ayrılabilir mi?

Tedarikçinin bu sıralamayı kullandığı doğrulanmadan yapılmamalıdır. Farklı kaynaklar genişlik, uzunluk, derinlik ve yükseklik sırasını farklı kullanabilir. Alan sözlüğü veya tedarikçi dokümantasyonu esas alınmalıdır.

Adet, set ve koli de XML birimi sayılır mı?

Ticari anlamda “satış birimi” olarak kullanılabilirler ancak santimetre, kilogram veya litre gibi fiziksel ölçü birimleriyle aynı veri türü değildirler. Paket miktarı ve satış biriminin fiziksel ölçülerden ayrı alanlarda tutulması daha güvenlidir.

XML'de ölçü bilgisi yoksa ürün görselinden tahmin edilebilir mi?

Güvenilir ürün verisi açısından hayır. Görsel perspektifi ve ölçeği yanıltıcı olabilir. Ölçü bilgisi doğrulanmış tedarikçi/üretici verisinden veya gerçek fiziksel ölçümden alınmalıdır. Normalizasyon eksik bilgiyi uydurmak için kullanılmamalıdır.

ÖLÇÜ STANDARDININ AMACI BÜTÜN ÜRÜNLERİ AYNI BİRİMLE GÖSTERMEK DEĞİL, AYNI TÜR VERİLERİ KARŞILAŞTIRILABİLİR HALE GETİRMEKTİR

118 için en önemli fikir budur.

Yanlış yaklaşım:

“XML'de gördüğüm bütün ölçüleri cm'ye çevireyim.”

şeklindedir.

Daha kontrollü yaklaşım:

ölçünün anlamını belirle → kaynak değeri koru → sayı ve birimi ayır → measurement type belirle → canonical birime dönüştür → ürün/paket ölçüsünü ayır → satış birimini ayrı yönet → varyant bağlamını koru → belirsiz ve nominal ölçüleri otomatik dönüştürme → kullanıcıya uygun gösterim birimi üret

şeklinde ilerlemelidir.

Örneğin:

Kaynak A

Uzunluk: 30 cm

Kaynak B

Length: 300 mm

Normalized:

length = 300 mm

Bu iki değer karşılaştırılabilir.

Ancak:

Kaynak C

Koli: 30 adet

değerindeki:

30

aynı veri sistemine sokulmamalıdır.

Çünkü:

30 cm fiziksel uzunluk,

30 adet ticari miktardır.

Benzer biçimde:

1 L kapasite

ile:

10 × 10 × 10 cm ürün boyutu

birbirine matematiksel olarak ilişkilendirilebilse bile aynı ürün özelliğini temsil etmek zorunda değildir.

Bir kap dış ölçüleri nedeniyle belirli geometrik hacme sahip olabilir; müşteriye verilen kapasite bilgisi ise ürünün kullanılabilir iç kapasitesidir.

Bu nedenle güçlü bir XML ölçü sistemi yalnızca sayıları çevirmemeli.

Verinin ne anlama geldiğini korumalıdır.