Microinvest Форум

[PHILIP]

Здравейте, ползвам вашия софтуер от 20 години. Минал съм през доста версии на вашия софтуер, както и имам международен опит със софтуер на световно ниво поддържащ база данни от над 12 милиона артикула.

Като цяло мнението ми за СКЛАД ПРО е много добро, но може да се доразвие много повече.

Ще отметна някой важни за мен аспекти които не намирам в СКЛАД ПРО и много се надявам да бъдат заимствани идеи в бъдеще.

1 во. Визията ми е много скучна. Използва се класическия дизайн на C# , който не блести особено с визия. Има много съвременни UI за C# - Пример - Modern UI Design.
Добро впечатление прави избора на икони към интерфейса - сегашните нещо не стоят добре ...

Започнах с визията защото тя е нещото което продава и за мен е нещо много важно - ама много. Силно препоръчвам за визия да използвате външна компания и да не се доверявате на вашите програмисти!

Много често срещана грешка програмата (кода) да води визията. Някой си почнал да пише код и давай с драг и дроп ги нагласяме и това е ... тук кутйка, там квадратче ... Много непрофесионално (поне за мен).

За съжаление мисленето на програмистите е логично и праволинейно и в съвсем друг аспект, докато дизайнерите мислят "разчупено" и неправолинейно и не се водят от кода.

дотук с дизайна.

2 ро. Организация на операциите. В съвременната търговия са се наложили стандарти за търговия B2B и B2C , които изискват различни подходи и реквизити. Много често се срещат и двете едновременно.

При B2B имаме т.н. схема на работа - REQUEST -> CONFIRMATION -> PURCHASE ORDER - DELIVERY


REQUEST - т.н. заявка за доставка - тук липсва функция за за одобрение.

Идеята е в даден обект с N потребителя всички или някой да могат да правят заявки - но само 1 или няколко да могат да я одобрят ! В противен случай заявката остава в DRAFT ( чернова).
Задължително опция заключване за редакция след одобрение.


CONFIRMATION - издава се от доставчика на база предходната заявка със актуални цени и количества.

PURCHASE ORDER - на база предходното заявителя потвърждава цените, количествата на доставчика и заплаща съответната сума за избраните от него - напълно или частично продукти/услуги.

Тук също е необходимо йерархични права за направата на окончателната заявка.

DELIVERY - т.н. Доставка тук се наблюдават 2 варианта - Частична или пълна Доставка (PARTIAL / FULLY)

при FULLY RECEIVED - се заприходява целия PURCHASE ORDER, а при PARTIAL само доставените продукти/услуги, след което те или се оцветяват в друг цвят в PURCHASE ORDER или редовете стават неактивни.

дотук с операциите


3 то. СКЛАД ПРО предполага, че обслужва складове - съответно стоката се подрежда в складовете и е необходимо STORE MENAGMENT или LOCATION MANAGER

В текущия софтуер има МЕСТОПОЛОЖЕНИЕ, но то е толкова примитивно че нямам думи. Необходимо е малко по разширено допълнение.

Масово това се изпълнява еднакво в софтуера: създава се дървовидна структура както категориите (аналогично) като съответно имаме няколко йерархични структури:

СКЛАД - > ОБЕКТ ( ПРИМЕР: ПОМЕЩЕНИЕ 1, ПОМЕЩЕНИЕ 2, БУФЕР, ЗАЛА ЗА ИЗДАВАНЕ) -> СТЕЛАЖ (РАФТ, ЧЕКМЕДЖЕ) -> РЕД -> ПОЗИЦИЯ ...

всяко местоположение трябва да има уникален баркод ( съответно този баркод се поставя на местоположението за сканиране )

съответно при приемане на стока с 1 безжичен баркод скенер трябва да може да се маркира продукта и след това местоположението и да се зачисли след запис съответното местоположение.

съответно всеки продукт може да има местоположение по дефоулт и да се запише там при доставка.

Отделно всяко местоположение трябва да може да се характеризира с широчина / дължина / височина / (обем) , товароносимост.

За да се използва това пълноценно обаче продуктовите данни трябва да се поразширят.

4 то. Продуктови данни

Тук май най много трябва да се наблегне на промените защото от 20 години не се е променило нищо в продуктовите детайли.

Според мен е необходимо да се направят групи от продукти


PRODUCTS - продукти за препродаване

CONSUMABLE - стоки за лично ползване които не се заприходяват в тези за продажба
SERVISE - услуги

с последните 2 може да се формира и мини счетоводство на ниво ОБЕКТ

Основната група продукти е добре да се разглежда обширно:


Продуктите трябва да имат Варианти и Опции и да могат да се комбинират.

Варианти - Номера на обувки примерно, Цветове

отделно за всяка комбинация трябва да има опция за детайли на опаковка с коефициент на трансформация:


ЕДИН БРОЙ | БАРКОД |ТЕГЛО НЕТО | ТЕГЛО БРУТО | ВИСОЧИНА | ШИРОЧИНА | ДЪЛЖИНА | ЦЕНА
КАШОН | БАРКОД |ТЕГЛО НЕТО | ТЕГЛО БРУТО | ВИСОЧИНА | ШИРОЧИНА | ДЪЛЖИНА | ЦЕНА
МАСТЕР КАШОН | БАРКОД |ТЕГЛО НЕТО | ТЕГЛО БРУТО | ВИСОЧИНА | ШИРОЧИНА | ДЪЛЖИНА | ЦЕНА
ПАЛЕТ | БАРКОД |ТЕГЛО НЕТО | ТЕГЛО БРУТО | ВИСОЧИНА | ШИРОЧИНА | ДЪЛЖИНА | ЦЕНА

Добре е да може да се използват и изображения за всеки продукт и то с възможност за повече от 1.

Отделно е необходимо в продуктовите детайли да се визуализират всички транзакции - ПРОДАЖБИ / ДОСТАВКИ
Отделно е добре за всяка стока да може да се обособят доставчици - защото е възможно за 1 стока да има повече от 1 доставчик и съответно се предполага и различни цени.



С горепосочените опции за опаковка е възможно да се направи и калкулация за съвместимост в склада ( разбира се това е опция )


5 то. Интеграция с външни системи.
Според мен е добре да се направи вариант с буферен Mysql да кажем в независима база данни предварително зададена от вас да може да се импортват и експортват данни, като това се управлява от склада .

Може да се експортват продукти, поръчки и какво ли още не с php, java script и тн.т.. Така всеки сайт ще може да се върже със СКЛАДА с минимални усилия.


Спирам дотук защото имам още 1000 идеи и няма да ми стигне още 1 ден. Надявам се да се разбира горе написаното, колкото и да е объркано