emm klo menurut saya... masukan2 diatas sudah mencukupi dan menurut
saya memang semuanya bisa diimplementasikan
tinggal disesuaikan dengan kebutuhan realita yang ada
saya yakin tidak akan bisa menyimpan semua data pada barcode walaupun
dengan pengkodean digit apapun bila semua informasinya harus ada di
barcode secara langsung (misalnya dari supplier mana, warna apa ukuran
apa dll)
menurut saya. cari lah kelompok2 yang benar2 diperlukan yang tentunya
tiap fashion store blum tentu sama. misalkan aja bagi saya ukuran
penting sekali
tetapi warna tidak penting. dikarenakan warna hijau bisa berfariatif.
dan juga 1 pakaian bisa memiliki banyak warna. dan belum tentu ada
warna dominan. dimana it's fashion. move so fast...
atau bisa juga ditambahkan data penempatan produk. misal di round 1
ato 10 (atau bisa juga dari departement apa)
yang tentunya akan sangat mempermudah dalam penempattan display barang
yang pasti harus ada counter didalamnya.
yang menjadi patokan menurut pendapat saya adalah, barcode harus bisa
memenuhi kebutuhan dalam operasional langsung (maksudnya dalam
lapangan langsung berhubungan dengan customer) sehingga akan
mempercepat kerja
lalu kondisi2 dimana diperlukan informasi seperti supplier dari mana,
berapa kali barang telah di repeat, barang dari cabang mana saya rasa
tidak perlu di tempatkan pada barcode. karena sangat tidak diperlukan
dalam pelayanan langsung di store.
hal ini hanyalah masalah internal store. yang dapat disimpan dalam
suatu database. dan dapat dicek langsung dengan merelasikan dengan
table barnag itu sendiri. seperti yang dikatakan teman2 sebelumnya.
jadi sebelumnya lihat kebutuhan lapangan dahulu untuk membentuk barcode
keluh kesah SPG sangat berperan penting dalam hal ini
barcode yang tidak terlalu panjang sangat membantu dalam operasional
dan informasi2 yang tertera dalam label barcode juga sangat berperan.
maaf klo sedikit membingungkan...
;p
On 10/8/08, Widi Satriya <widi.satria@...> wrote:
> uniknya dari Fashion itu stock nya per penggolongannya [Tipe, Supplier,
> Ukuran, Warna, Model, dll].
> dan scalabilitas dari penggolongan ini tidak ada yang baku untuk berbagai
> client.
>
> saya setuju dengan teman-teman sebelumnya tentang pengkodean, karena terlalu
> dinamis, maka pakai saja yang simple dan increment, karena suatu saat bila
> ada penambahan penggolongan, atau merubah susunan penggolongan tidak usah
> merubah semua kode barang yang sudah ada. untuk masalah readability biar
> sistem yang menjelaskan seperti apa barangnya untuk kode tersebut. hanya
> yang perlu di perhatikan adalah *pencarian* *data berdasarkan
> penggolongan*tersebut.
>
> Bila stock opname pun si user tidak perlu susah menebak baju itu kode
> barangnya apa.
>
> laporan yang paling cocok adalah berbentuk Matrix per penggolongan.
>
> kalo sudah simple kode barangnya, saya pikir perlakuannya akan sama dengan
> barang biasa.
>
>
> [Non-text portions of this message have been removed]
>
>