Система за управление на електронната търговия на едро. Куба

резюме

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

на едро продукт-продажби-система

Това преследва целта за решаване на проблема с паричната двойственост и собствените форми на плащане, които правят невъзможно прилагането на други съществуващи системи.

Получената система има подобрения и допълнения на търговски функционалности в приятелска и лесна за използване среда; В допълнение, той гарантира сигурността и целостта, изисквани от данните, които обработва, ускорява и улеснява процеса на продажби на едро на продукти.

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

Ключови думи

Софтуер за управление, електронна търговия, продажби на едро.

абстрактен

Този разследващ проект представя предложение за система за търговия на едро съгласно действащите разпоредби за извършване на тази дейност в Куба. Тази система има за цел да реши проблема с двойната валута, формулярите за плащане и други теми, които правят невъзможно прилагането на съществуващите системи.

Резултатната система подобри агрегирането на търговски функции в приятелска и по-лесна среда за използване. Освен тази система гарантират сигурност и цялост, необходими за управлявани данни, ускоряващи и улесняващи процеса на продажба на продукти на едро.

За разработване на системата се използва пъргав метод за управление на проекти: Scrum.

Ключови думи

Електронна търговия, система за търговия на едро

Въведение.

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

Електронната търговия се роди като израз на ефективността и да бъде по-продуктивна; като желание за цялостно задоволяване на новите нужди, под обектива на технологията, която играе съществена роля за тяхното материализиране. Куба не е освободена от извършване на търговия, така че тя засилва навлизането си на международния пазар по всякакъв начин и особено чрез електронна търговия.

Икономиката на страната обаче има специални характеристики, които правят невъзможно прилагането на съществуващи системи, тъй като те не разполагат с идеалните начини да извършват плащания и да обработват циркулираща двойна валута, наред с други регулации. Поради тази причина може да се заяви, че няма компютърна система, която да може да продава на едро, която да отговаря на характеристиките на кубинската търговия. По този начин разработването на система за управление на продажбите на едро на продукти като инструмент, който е в съответствие с регулациите, установени за Куба, ще благоприятства развитието на електронната търговия, предоставяйки ползи за икономиката на страната.

Съществуващи системи за електронна търговия

Съществува широка гама от платформи, разработени по различни технологии за осъществяване на електронна търговия. Само да споменем няколко, можем да изброим Gesticom B2B, TornadoStore ™, AB-Shop 3. Всички те са много удобни за потребителя и атрактивни за създаването на всякакъв вид виртуален магазин. Някои от тези платформи са дори безплатни и с отворен код. На Куба обаче не са приложими нито една от тях, нито системи за инвентаризация, които ги поддържат.

Причини, които изключват използването или повторната употреба на тези системи:

Те вече са се осмелили да използват тези системи и са направени пластири и модификации на продажбите на дребно, които извършват, за да ги адаптират към търговците на едро, определени в Куба. Процесите, които този модел не са тези, прилагани в страната между другото в който е замислен Договорът и Процесът на продажба.Начинът на договаряне на търговски маржове, кредити и платежни инструменти не са подходящи или използвани в Куба.

Процесът на фактуриране, обработван от изложените системи, не е описаният за страната.

Циркулацията на двойната валута не може да се управлява от тези системи или от съответните им запаси.

Като се има предвид, че основните функции на системата трябва да са продажбите и фактурирането, свързани с управлението на търговските маржове и кредити, има много малко за повторно използване на съществуващите системи: дизайнерски идеи, добри практики за програмиране, модели…

В момента започва да се насърчава развитието на електронната търговия в страната и се правят първите стъпки в продажбите на едро, насочени към фирми или юридически лица. Това дава възможност за извършване на изчерпателно проучване на изискванията, така че първата платформа за електронна търговия, разработена, способна да работи с кубинския търговски модел, да бъде възможно най-ефективна.

Идеята за създаване на нова платформа се подкрепя и от използването на ориентирана към услугата архитектура, която позволява по-лесното общуване между системите и по този начин по-лесно постигане на тяхната интеграция (трябва да е възможно интегрирането на получената система с ERP-Cubaв момента се разработва). Изложените системи използват хибридна архитектура между клиент-сървър и 3 слоя, която не улеснява процеса на интеграция.

Методология за развитие

"Scrum" е методология за управление на проекти, изложена от Hirotaka Takeuchi и Ikujiro Nonaka, в статията Новият продукт

Игра за развитие. "Основното правило на тази методология е, че конкурентният пазар на технологични продукти, в допълнение към основните понятия за качество, цена и диференциация, също изисква бързина и гъвкавост." (Takeuchi, 1999) Характеристиките на Scrum, които предполагаха решението да се избере тази методология, а не друга, са изброени по-долу:

Това е гъвкава методология за разработка.Тя е предназначена за малки екипи за разработка (не повече от 8 души). Малко артефакти са посочени, елиминирайки ненужната "документация" и отделяйки повече време за внедряването й. Тя позволява доставката на функционален продукт в края на всеки спринт. Дава възможност за адаптиране на функционалността въз основа на бизнес нуждите на клиента. Позволява ежедневна визуализация на проекта. Той има ограничен и изпълним обхват. Прилага се в екипи, интегрирани и ангажирани с проекта и които са самостоятелно администрирани. Не Това е методология на анализа, не на дизайна (въпреки че може да се адаптира така, че да е), а на управлението на работата. Може да се прилага при различни модели за качество (като CMMI), тъй като те ви казват какво трябва да направите, т.е., те ви казват, че трябва да управлявате проекта,но те не ви казват как. Именно тук идва SCRUM като модел за управление на проекти.

Описание на бизнес процесите.

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

Тази работа има за цел да моделира процесите на продажбите на едро в съответствие с предписаните предписания по начин, който да съответства на спецификациите на търговията в Куба. Тези конкретни разпоредби са изброени по-долу:

Наемане и процес на продажби

За да извършва продажби на едро, търговската зона или специалистът на отдела трябва да съставят досието на всеки купувач, което ще съдържа следните документи:

Решение за назначаване и правомощие на лицето, упълномощено да подписва Лиценз за договори от Централната банка на Куба, който разрешава на предприятието или дружеството да оперират в чуждестранна валута, надлежно актуализиран.

Протокол, акт, решение, документ, нотариално заверен пред нотариус или друг правен документ за учредяване на предприятието или дружеството, заедно с корпоративната му цел. Подписан и отсечен договор за продажба, съгласно договора Pro forma de (приложение № 4)

Договорите за продажба на едро ще бъдат насърчавани от отдела за продажби, производство или обслужване, като коригират клаузите на проформата на договора (приложение 4) към купувача, с когото се подписва. След като условията, при които ще се изпълни договорът, и купуващите интереси на клиента на територията са уточнени с Купувача, те трябва да бъдат изпратени на юрисконсулт на провинциалния клон за преглед.

Договорът за покупка на едро ще бъде подписан от името на образуванието, което публикува системата и ще бъде подписан от директора на териториалния клон и търговския директор. Договорите ще обхващат всички единици за продажба на едро на територията, предварително договорени в договорите. В Договора Дяловете на територията, където продажбите на едро на Купувача, с които е подписан Договорът, трябва да бъдат посочени в изрично приложение, определящо тези, които ще бъдат пуснати на пазара във всеки от Единиците.

В никакъв случай договорите за продажба на едро ще обхващат единици за търговия на едро или райони от други територии. След подписване на договора за търговия на едро, юридическият съветник на провинциалния клон удостоверява копията на единиците, към които договорът има обхват. Търговската дирекция на клона е отговорна за предоставянето на посочените заверени копия на дяловете, обхванати от договора.

В случай на нови клиенти, провинциалният клон ще поиска номер на клиента от търговската дирекция на централата, както е установено на корпоративния номенклатор на клиенти и доставчици. Единици, които нямат заверени копия на договорите или гореспоменатите договори не се актуализират и Клиентският код не е активиран в системата, няма да могат да извършват продажби, докато документацията не бъде актуализирана в досието на Устройството. установи и активира номер на Клиента в Номенклатурата.

Договорите, които са подписани с фирми или държавни организации за продажба на модули на техните работници, ще имат Специализиран отдел, определен за продажби на дребно на едро и няма да има обхват за други звена, територии или видове продажби.

За договорите за продажба с клоновете на фирмите

Чуждестранните компании със седалище в Куба, както и операторите на зоните за свободна търговия, ще бъдат подписани само от техен представител, надлежно упълномощен за това. Документите, необходими за подписване на договори с тези предприятия със следното:

Лиценз на Търговската камара или MINVEC, според случая, с който се уведомява за статута му в страната.Съдържание за акт, резолюция, нотариално заверен документ или друг правен документ от учредяването на субекта. Досие на клиента, където са посочени длъжностните лица, упълномощени да извършват покупки.

Договорите с посолствата и консулствата ще бъдат подписани от Посланика и / или Представител. В досието на клиента, в допълнение към свързаните данни, ще бъде приложено копие на картата, издадена от MINREX за длъжностните лица, упълномощени да извършват покупки, и копие от картата на Агенцията по заетостта на длъжностните лица и работниците, упълномощени да събират стоки.

Договорите, които са подписани с проектите или програмите за сътрудничество на Министерството за чуждестранни инвестиции и икономическо сътрудничество, трябва да представят заверено копие от MINVEC на бюджета и условията на проекта, одобрени със задълженията на контрагентите, които трябва да бъдат подписани от тези колеги и MINVEC.

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

По време на продажбата звеното ще преглежда досиетата на клиентите и тяхната валидност, както и ще провери дали заинтересованото лице е надлежно регистрирано в номенклатурата на клиента.

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

Чуждестранни търговски дружества, оператори на свободни зони, банкови представителства и проекти или програми на MINVEC; Те ще се извършват в съответствие с установеното в тази процедура в съответствие с Резолюция 222/2003, разрешение I-885/2007 и Инструкция 2/2003 на цялото Министерство на вътрешната търговия.

За да извърши продажбата на клиентите, споменати в предишния раздел, звеното ще изисква, в допълнение към горното, представянето на следните документи:

За представителства на чуждестранни банки:
- Писмо с искане за покупка със списък на продуктите, които трябва да бъдат закупени и количество Резолюция на Централната банка на Куба, която разрешава на банковото представителство да оперира в Куба.
За клоновете на чуждестранни търговски дружества и смесени дружества:
- Купете писмо за заявка със списъка на продуктите, които трябва да закупите и количеството.

Лиценз, издаден от Търговската камара на Република Куба, за дейност в страната.

За проекти и програми за сътрудничество, одобрени от MINVEC:
- Заверено копие от MINVEC на бюджета на проекта или програмата. o заверено копие от MINVEC на техническото задание на одобрения проект със задълженията на контрагентите и техните подписи и MINVEC.
За операторите на свободни зони:
- Купете писмо със заявка със списъка на продуктите, които ще закупите, и количеството Решение на Министерството за чуждестранни инвестиции, което ви акредитира като Оператор.
За посолства и консулства:
- Купете писмо със заявка със списъка на продуктите, които ще закупите, и количеството.Идентификация, която ви акредитира като член на Дипломатическия корпус, издаден от Министерството на външните отношения на Куба.
За компании и OACE:
- Предприятията ще представят правната документация, установена в системата за договори за търговия на едро и други изисквания, установени в тази процедура, без да изискват други специални разрешения за продукти, които нямат специални разпоредби. ü За религиозни институции:Висшият орган на религиозната институция, който се интересува от покупката, ще издаде подписан и монетиран документ, където той отразява нуждите, които изисква, местоназначенията му и спрямо каква дейност се осъществява. В случаите, когато се изискват лични средства за хигиена, хигиена и почистващи препарати, това трябва да бъде придружено от клетва за броя на хората, които се обслужват в субекта по местоназначение на продуктите. Когато искането се отнася до електрическо оборудване или домакински уреди, промишлени кухни или велосипеди с или без мотор, религиозната институция трябва да подаде искане за разрешение до заместник-министъра на Министерството на вътрешната търговия и след като бъде издадено, то ще бъде обработено от търговското вицепрезидентство с клоновете и отделите, След като бъде получено разрешението на търговския вицепрезидент или заместник-министъра на вътрешната търговия,В зависимост от одобрението и религиозната институция поиска покупката, провинциалният клон ще се консултира писмено с лицето, което посещава религия в провинциалния комитет на територията, за да издаде одобрението си за продажбата. В случай, че напуснете изцяло или частично, това трябва да бъде съобщено писмено на търговското вицепрезидентство. Във всички случаи звеното, което получава искане за покупка от религиозни институции, трябва да обработи и получи писмено разрешение за извършване на продажбата. Документите за упълномощаване и консултация се подават в досието на договора. Когато се получи заявка за оферта от клиент за покупка на едро на стоки, които не са в съответствие с нормата или се оценяват обемите или продуктите, които не съответстват на дейността, извършвана от Дружеството или Институцията,Ще бъде поискано своевременно искането да бъде издадено или заверено от ръководителя на дружеството или институцията чрез документ, отразяващ заявените продукти и количествата.

Търговски маржове, кредити и платежни инструменти

Определянето на цената ще се извърши въз основа на изчисляване на всички разходи на продукта до пускането му в продажба, от които се установяват следните минимални търговски маржове:

За подсметките на автомобилни части и строителни материали = себестойност x x 80 за продажба на стоки = себестойност x 1,30 за гастрономия = 10% по-ниска от продажната цена на дребно за услуги = Лист на общите разходи x 1,30 Чуждестранни фирми и институции, дипломатически корпус = цена на разходите х 1,40 религиозни институции = цена на разходите х 1,60 за продажба на едро на дребно (модул) = цена на разходите х 1,30

(Цените за продажба на стоката, продадена в единици за продажба на модули, ще бъдат закръглени до 0 или 5, следвайки същата процедура, както при формирането на цената на дребно)

В акта за продажба могат да се прилагат по-високи цени в зависимост от качеството на продукта, позицията му на пазара и договарянето с клиента.

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

В предложенията трябва да се направи оценка:

Обем на продажбите Инвентар и оборот на продукта Характеристики на купувача, на когото се предлага да продаде предложен търговски марж Други количествени и качествени елементи, които го подкрепят.

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

Събирането ще се извърши чрез представяне на чек, издаден от купувача на продавача, получени и кредитирани банкови преводи по сметката на Продавача и чрез магнитна карта в момента на продажбата, следвайки процедурата, установена за тази система за събиране.

Чековете с суми над 500 CUC трябва да бъдат заверени от Банката.

Продажбите на едро ще се извършват само на юридически лица. В никакъв случай няма да се получават чекове или други платежни инструменти от физически лица.

За продажби на едро на продукции и услуги, включително продукти, които са част от тях, могат да се издават кредити до 30 дни.

По изключение при продажбите на стоки на едро търговските кредити ще бъдат издадени до 30 дни след фактурирането, които предварително ще бъдат упълномощени писмено от търговския вицепрезидент по предложение на директора на съответния клон; за които трябва да се извърши предварителен анализ на следните аспекти:

Количество на стоката, която ще бъде продадена. Призната икономическа платежоспособност на клиента. Ако е редовен клиент, точност в предходните плащания. Удобство на компанията да извърши предложената стока, която да бъде продадена на кредит.

Неспазването на плащането в срока, определен в предоставения Търговски кредит, както за продажби на едро на стоки, разрешени за кредит, така и за продукции и услуги, прави невъзможно извършването на нови продажби до изплащане на задълженията.

Неизпълнението на плащанията на стоки, изключително разрешени за продажба на кредит, автоматично отменя разрешението на търговския кредит на неизправния клиент и продажбата може да бъде възобновена, след като остарелият дълг бъде уреден с плащането срещу доставката на стоката.

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

Вземанията, които могат да бъдат генерирани от неспазване на плащането, ще бъдат обект на активно и систематично управление на събирането от звеното, което го регистрира, като се приемат установените мерки, включително представяне пред компетентните съдилища.

фактуриране

Търговската зона или специалистът на отдела ще подготвят предфактура или оферта за продажба на клиента, като определят клиентските данни, данни за продукта, количества и цени, както и датата на валидност на офертата, без да създават задължения за резервиране на продуктите, Когато продажбата ще бъде направена, препоръчително е да резервирате продуктите, трябва да осигурите финансово тяхното реализиране и да определите крайния срок за това.

В момента на продажбата Икономическата зона ще изготви окончателната фактура за продажби в съответствие с представената оферта, като предостави на купувача оригинала, надлежно подписан и изсечен. Дубликатът се подава в отдела за продажби и три екземпляра се издава на превозвача.

Фактурирането на едро ще се извършва в съответствие с разпоредбите на

Инструкция № 15/2006 на МФП. Задължение на икономическия ръководител или счетоводител на звеното е да подаде копие от всяка издадена фактура, надлежно подписана и изсечена от упълномощените лица. Печатът за плащане трябва да бъде записан във фактурите, чието събиране е направено и проверено, независимо от използвания платежен инструмент. Не трябва да се правят продажби или фактури, без предварително да се провери акредитацията на плащането. В случаите, установени по тази процедура, когато се предоставят търговски кредити, датата на плащане трябва да бъде посочена във фактурата като препратка. В случаите, когато Чекът се използва като платежен инструмент, копие от чека, получено от клиента, трябва да бъде подадено с фактурата. В случай на други платежни инструменти, ще остави копие от ваучера, което доказва плащането в момента на фактуриране.

Описание на предложената система.

За изпълнение на целта, предложена в началото на тази работа и като се вземат предвид предложените бизнес процеси, предложената система ще се състои от три сайта:

HostingService (Service Server): Това е основният сайт на системата: съдържа набор от публикувани уеб услуги, които трябва да позволят да се осъществят всички описани по-горе процеси. Всички други сайтове работят с услугите, посочени в това. AdminSite (Административен сайт): Това е сайт, предназначен за работа на длъжностни лица и който изпълнява всички функции, посочени за тях. Този сайт не е много привлекателен, като се има предвид крайните му потребители. VirtualStore (Virtual Store): Виртуалният магазин ще бъде видян от клиентите. Той има всички функционалности, внедрени във всеки онлайн магазин и вие коригирате необходимите към кубинските особености.

Роли на потребителя

Предварително замислените роли за действие върху системата за управление на продажбите на едро на продукти са изброени по-долу:

Обосновка на ролята

Потребител Това е всеки човек, който иска да получи достъп до Системата и няма нужда от автентификация, за да се движи в публичните страници.

Служител за специализация на потребителя: Това е лице, принадлежащо към единицата или продажби на едро, оторизирано да извършва различни действия във виртуалния магазин. Обобщение на администратор, търговски, правен и продавач.

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

Търговска специализация на длъжностното лице, отговарящо за обработката на новите продукти, получени от инвентаризационната система и определяне на продажната цена съгласно правилата за формиране на цените.

Правна специализация на длъжностно лице, което отговаря за „блокиране“ на достъпа до клиенти с проблеми от този характер, като им пречи да купуват в онлайн магазина.

Специализация на продавач, която обработва поръчки, стартирани от клиенти, или създава нови в тяхно присъствие на фиксиран брояч на продажби във физическия магазин на едро.

Специализация на клиента, идентифицирана с договор и представляващ юридическо лице, упълномощено да извършва покупки на едро в магазина.

N-ярусна архитектура, ориентирана към услугата

Ориентирана към услуги архитектура (не непременно SOA) улеснява интеграцията с други местни и външни системи на други компании, отваряйки врати за системата за търговия на едро с електронна търговия; тя улеснява повторното използване, тъй като услугите могат да бъдат консумирани от редица приложения или те могат да бъдат комбинирани помежду си, за да образуват други. В комбинация с n-слоева архитектура той улеснява поддръжката и гъвкавостта.

Фигура 2. Организационна форма на услуги и интерфейси, които могат да ги консумират.

Системата е разделена на следните слоеве:

Слой за достъп до данни на слоя за оперативна съвместимост

Фигура 3. Общ логически изглед

Системата комуникира с потребителите чрез интерфейсния слой и с други системи чрез други услуги.

Комуникацията на обслужващия слой с други системи и с графичните потребителски интерфейси ще се основава на SOAP съобщения.използвайки индустриалния стандарт WS- *. Бизнес слоят осигурява фасада на клиентите, а останалите услуги си сътрудничат транзакционно, за да изпълняват бизнес функции.

Услугите използват слой за достъп до данни, за да взаимодействат с базата данни. Този модел е гъвкав по отношение на типа база данни, която да използвате. Използването на NHibernate ще позволи използването на всеки друг мениджър само чрез промяна на съответните настройки.

разгръщане

Архитектурата на системата позволява вертикална и хоризонтална мащабируемост. Системата е доста гъвкава при избора на вариант за внедряване. Следващите диаграми показват възможните конфигурации за внедряване и разпределението на приложенията в тези варианти.

Уеб приложение и услуги

Фигура 4. Вариант на внедряване

Имайки предвид, че някои услуги са вътрешни, а други са частни, се препоръчва следната конфигурация:

Фигура 5. Препоръчителен вариант за разполагане.

Сигурност

Системната сигурност се прилага в 3 основни измерения: Thin Client, Application Server и DB Server.

Фигура 6. Размери на сигурността на системата

Най-големите заплахи за сигурността на клиента са Cross Site Scripting (XSS) и SQL Injection. Съображенията за отстраняване на тези пропуски са следните:

XSS

Използвайте POST mehotd, а не GET и направете проверка на данни от страна на сървъра.

SQL инжектиране

Базата данни е създадена на принципа на най-малко привилегия. Потокът от SQL заявки се регулира чрез NHibernate. Грешките са филтрирани, изключенията са хвърлени от сървъра, за да се предложи описанието на безплатните данни, които описват начина, по който са структурирани. образувания.

За да елиминира възможните атаки срещу сървъра на приложения, услугата за сигурност се реализира в инфраструктура за публични ключове (PKI), която представлява комбинация от хардуер и софтуер, политики и процедури за сигурност, които позволяват изпълнението с гаранции за криптографски операции като криптиране, цифров подпис или неотхвърляне на електронни транзакции.

По същия начин, сигурността, предоставена от ASP.NET, беше повторно допълнена, така че методите на услугата за сигурност се използват и по този начин предоставя начин за удостоверяване, оторизация и контрол на достъпа на потребителите. За удостоверяване на услугите се генерира „докосване“ на сигурността, което изтича след 15 секунди.

Сървърът за данни също работи на принципа на най-малко привилегия и правилата за защита на мениджъра са конфигурирани (SQL 2005 Express в този случай, но конфигурируем във всеки друг мениджър, който е определен). Приложението контролира, че заявките, отправени към сървърите, идват от предварително дефинираната подмрежа за достъп на потребителите във всеки случай, което прави възможно по-нататъшното повишаване на нивата на сигурност на системата.

И накрая, настройките са направени за работа с ограниченията на историята и паролата, а фактурите, генерирани от длъжностните лица и клиентите, са цифрово подписани, което гарантира неотхвърляне на действията, които предприемат. По същия начин, с използването на аспектно-ориентирано програмиране и Spring Framework, се гарантира генерирането на регистрационни файлове (следи), които са регистрирани в уеб сървъра и в базата данни.

Задръжка на продукта / стека на продукта

Изискванията, разработени за система или продукт, са изброени в продуктовата програма. Собственикът на продукта е отговорен за неговото съдържание, приоритизиране и достъпност: той никога не е завършен и се използва при планиране на проекти, просто е първоначална оценка на изискванията. Product Backlog се развива паралелно, тъй като продуктът и средата, в която работи, са динамични; постоянно управлява промени, за да идентифицира какъв трябва да бъде продуктът: подходящ, конкурентен и полезен. Докато съществува даден продукт, съществува и Backlog на продукта.

Id на модула Описание Състояние

Критични изисквания

1 HostingService Системата получава информация от „ 100% система за инвентаризация“ за съществуването на продукти

Отивам	модул	описание	състояние
		предназначен за "зоната за онлайн продажби" (Код на продукта, CSTA или фамилия, име, описание, количество, цена, цена на дребно и процент на отстъпка за приложими клиенти.
две	AdminSite	Системата очаква административен процес, за да подготви тези продукти за представяне пред клиентите, този процес включва: Определете или създайте изображението (ите) на продукта, ако съществува. Определете продукта към категорията, към която принадлежи. Маркирайте продукта като готов за продажба (активен).	100%
3	AdminSite	Потребителската регистрация е 100% административно от някои служители на компанията, които ще имат потребител в Системата с роля на потребителски администратор. ü Има няколко типа потребители на сайта: Клиенти, Длъжностни лица. ü В рамките на официалните потребители са следните роли: o „Администратор“ общ административен потребител. o „Администратор на потребители“, отговарящ за регистрирането на клиентски потребители в Системата. o „Търговски администратор“, отговарящ за обработката на нови продукти, получени от системата за инвентаризация, и определяне на продажната цена. o "Юридически администратор", който отговаря за "блокирането" на клиенти с проблеми, за да им попречи да купуват в онлайн магазина. o „Търговски продавач“ потребител на Системата, който обработва поръчки, стартирани от клиенти. ü Клиентските потребители могат да бъдат намерени в следните роли:

Id на модула Описание Състояние

или „Оторизиран клиент“ купувач, идентифициран с договор и представляващ юридическо лице.

4 AdminSite Системата трябва да съхранява следната 100% информация за клиента: Име на компанията, търговски регистрационен номер, ако сте вътрешен клиент, ако сте дипломатически клиент, ако сте клиент в една валута, в случай че плащате с чек „ срок ‟укажете броя дни.

5 AdminSite Системата трябва да се справи със 100% механизъм

, те се отнасят за конкретен клиент или за конкретен продукт:

ü Конкретен клиент: Някои предпочитани клиенти имат процент отстъпка от всички покупки, които правят, докато това предпочитание е валидно. Този процент се определя от бизнес мениджъра. Ако клиентът е „предпочитан клиент“ при покупка, тази отстъпка ще бъде приложена към общата сума на покупката и други отстъпки няма да продължат да се прилагат.

ü Специфичен продукт: Някои продукти имат процентна отстъпка от продажната си цена. Този процент е определен от търговския администратор. При покупка отстъпките ще се прилагат за тези продукти, които имат такива, стига настоящият клиент да не е преференциален, в този случай само техният процент се дисконтира от общата сума, без да се вземат предвид отстъпките.

Необходими изисквания

6 VirtualStore Системата трябва да показва на клиентите следната 100% информация за одобрените продукти и организирана по определени категории: изображение, име, продажна цена.

7 VirtualStore Системата трябва да показва на клиентите 100% подробна информация за конкретен продукт, показваща: изображение, продажна цена, име, описание, количество на склад.

Отивам	модул	описание	състояние
8	VirtualStore	Системата трябва да осигури търсачка за продукти	100%
9	VirtualStore	Системата ще покаже на потребителя наскоро посетените продукти по време на посещението им в сайта.	100%
единадесет	VirtualStore	Системата трябва да осигури „пазарска количка“, в която можете да съхранявате продукти, докато не искате да купувате. ü Артикулите в пазарската количка трябва да продължат да бъдат налични при бъдещи посещения на сайта, докато не продължите да купувате или продуктите не бъдат премахнати от системата. ü Системата трябва да позволява промени в количеството или вида на продуктите, добавени в пазарската количка. ü В количката за пазаруване Системата трябва да показва количеството на всеки продукт и общата сума. ü Ако даден продукт престане да съществува при актуализиране или отваряне на пазарската количка, ще се покаже, че ще подчертае липсващия му продукт.	100%
12	VirtualStore	Количката трябва да позволява съдържанието й да бъде фактурирано предварително. ü Системата ще подготви предварителна фактура, която съдържа името, описанието, продажната цена и количеството на всеки избран продукт и резюме с общата сума, която трябва да се плати. ü Системата ще съхранява история на предварителните фактури за бъдещи консултации, тази информация е частна за клиента, но достъпна от администраторите. ü Предварителната фактура ще бъде видима за клиента за време X, което може да се конфигурира от администратора.	100%
13	VirtualStore	След като бъде направена предварителната фактура, Системата трябва да позволи "резервиране на стоката". ü Системата ще резервира за време X, конфигуриращо се от администратора, заявената стока в определена предварителна фактура. Ако през това време споменатата фактура не е платена, то	100%

Отивам

модул

описание

състояние

стоката няма да бъде запазена. Тази опция се конфигурира от администратора, който избира дали резервацията е активирана или не.

ü Системата генерира „забележка за резервация на стоки“, която съдържа меморандум за клиента за времето, в което стоката ще бъде резервирана, и условията за резервация.

VirtualStore

След като бъде направена предварителната фактура, Системата трябва 100% да разреши „да купува стоката“.

ü Системата трябва да провери дали продуктите и количествата, добавени към фактурата, все още са налични за текущата покупка и да предприемат съответните мерки, в случай че не са.

ü Клиентът трябва да избере вида на плащане: Чек, акредитив, менителница, онлайн плащане или плащане в брой. Плащането в брой може да се комбинира с Проверка за случай, че чекът на клиента е по-малък от сумата на фактурата, плащанията в брой се приемат до $ 0,99, системата генерира разписка за плащане. За плащане с чек или менителница или пари в брой, клиентът ще предостави съответните данни. Ако клиентът плати повече от сумата на фактурата, Системата генерира акредитив. Системата спестява акредитивите и уведомява системата за фактуриране.

Административно акредитивите се анулират. За да извърши плащането и Системата да счита поръчката или предварителната фактура „платена“ и да продължи процеса, клиентът трябва да се появи в търговските помещения на Дружеството и длъжностното лице трябва да обработи поръчката, както е обяснено по-долу в този документ.

ü Системата трябва да вземе предвид следните правила при изчисляване на общата сума на поръчка:

o За клиенти (чуждестранни фирми, които нямат сметка в MN) на

Id на модула Описание Състояние
единна валута: таксува се само компонента на CUC. o За външни клиенти, които плащат в една валута: MN сумата се добавя към CUC без никакво преобразуване. o За клиенти с отстъпка в CUC и събиране в MN: стойността на MN се приспада от CUC без каквато и да е конверсия и се начислява отделно: CUC с отстъпката и пълната MN. o За вътрешни клиенти основната цена се начислява в CUC и MN. o За дипломатите цената на дребно се начислява, но се изважда приложимият процент за някои продукти. ü След като фактурата е генерирана, системата уведомява потребителя за дните, в които трябва да съберат стоките, това е фирмена политика и не зависи от вида на продуктите, които са закупени.
Незадължителни изисквания
15 AdminSite Системата трябва да осигури 56% работен интерфейс за търговски персонал в търговските помещения на компанията: ü Системата трябва да показва подробности за поръчките или предварителните фактури и фактури. ü Системата трябва да позволи на длъжностно лице да обработва поръчка, направена от клиент, докато той присъства. o Служителят трябва да избере реда. o Ако плащането е по менителница, чек или в брой, то трябва да се извърши ръчно и системата трябва да позволи маркирането на поръчката като платена. В случай на Кеш, Системата генерира разписка за плащане. o След като поръчката се обработи, Системата се държи същото, както ако е обработена онлайн: стоката е запазена за
Отивам	модул	Описание Състояние
		Вярно е, че закупените продукти се отстъпват от търговската зона. ü Системата трябва да позволи на законните администратори да замразят клиент. Тези клиенти не могат да правят покупки.
16	VirtualStore	Системата ще публикува формуляра, използван от 65% от Компанията, за да стане купувач.

Допълнителни изисквания

Външен вид или външен интерфейс:
- Опростен дизайн, лесен за използване и интерактивен интерфейс, за да улеснят работата на потребителя със Системата Перфектно рамкиран дизайн за 1024 × 768 резолюции, но готов за разглеждане в други резолюции.
ползваемост:
- Инсталирането на системата носи със себе си по-голяма скорост при продажбата на продукти на едро, което прави процеса много по-ефективен.
Софтуер:
- Приложението е хоствано на IIS или Apache уеб сървър с инсталиран модул за компилиране на страницата "aspx". Сървърът на базата данни трябва да бъде SQL Server 2005 или PostgreSQL, въпреки че всеки друг може да бъде инсталиран, като го посочите в системната конфигурация. Всички машини клиентите трябва да имат инсталиран браузър, за предпочитане Internet Explorer версия 5.0 нататък, те също могат да бъдат: Mozilla FireFox, Netscape и Opera

(последните версии).

Също така, Flash Player версия 6.0 или по-нова е инсталирана за показване на банера (по избор).

Преносимост:
- Приложението може да се стартира в повечето операционни системи като Microsoft Windows 98 / Me / 2000 / XP и Linux, като последната инсталира Linux версиите на софтуера, посочени в тези изисквания.
Хардуер:
- За да работите със системата ефективно, е необходима сървърна машина, която трябва да има най-малко следните характеристики: Pentium IV със 768 MB RAM, микропроцесор 3.00 GHz и мрежова карта с протокол 10/100 MB / s. клиентски машини: 16-битов или по-висок графичен процесор с разделителна способност 1024 × 768 пиксела или по-висока, процесор 600 MHz и 64 MB или по-висока RAM.

Те трябва да бъдат свързани в локална мрежа с 10/100 MB или трябва да имат модем за набиране с 128 Kbps връзка.

Практически принос и решения.

Първи стъпки

След инсталиране на системата, следните елементи трябва да бъдат конфигурирани за нейната правилна работа:

Метаданни: Тази концепция възниква за съхранение на данни, които не са замислени в обектите на проектираната база данни. Например: Системата съхранява броя на договорите, датата на създаване и по желание, ако е предназначена за компания (в противен случай това е лице); ако искате този договор да има нова собственост „X“, той се определя като метаданни на договора и типът данни се уточнява и ако се изисква при попълването на формата. По този начин, когато се представи формулярът за договор, предварително зададените полета за него и тези, добавени чрез метаданни, ще бъдат изрисувани.

Роли: Независимо от потребителските нива, които са установени за основната работа на системата в техните конфигурационни файлове, те могат или не могат да съществуват. За използването на системата с персонализирани роли, това образувание е създадено, отговарящо за управление на дефинициите на системните роли.

Категории: Системата работи с фамилиите (или агрегатите), предоставени от системата за инвентаризация, или позволява тяхното персонализиране. Това определение на категориите е необходимо при инсталиране на системата, за да се организират по-късно продуктите.

Монети: Системата е замислена с идеята, че може да бъде конфигурирана за използване на 1, 2 или 'n' монети. За целта е създадено едноименното предприятие, което отговаря за запазването на своите спецификации. Те ще бъдат използвани за определянето на цените на едро, както е обяснено по-късно.

Мерни единици: Продуктите, които се продават, могат да бъдат третирани както чрез техните базови мерни единици (от системата за инвентаризация), така и чрез еквивалентните дефиниции в системата. За тях се създават съответно субектите UM и Equivalence.

Съдържание: Определението на съдържанието в HTML формат ще бъде показано на първа страница на определения сайт. За това има редактор на страници във визуален WYSIWYG формат.

Останалите елементи са включени в системата или чрез сайта на администрацията, или чрез уеб услугите, публикувани за тази цел.

Управление на мултивалюта и формиране на цени на едро

След като бъдат идентифицирани „n“ валутите, с които ще работи системата, трябва да бъдат създадени правилата (ите) за формиране на цените. За това има форма, в която търговският администратор на системата въвежда своите спецификации, като най-важната е „формулата“.

Тази формула не е нищо повече от обикновен израз в следния формат:

( w {1,} ( d {1,}) *;) *

Низ от знаци, които трябва да съответстват на идентификатора на формулираната валута, математически оператор, стойност на разпределение и край на израза, определен с точка и запетая (;). Случаят с регулярни изрази извън посочения формат ще бъде игнориран от оценителя. Идеята е да се постигнат спецификации като тази:

CUC * 9/10; CUP;

В този случай клиентите, засегнати от показаното правило, ще имат резултат от оценяването на писмената функция като цена на едро с цената на дребно във всеки от нейните компоненти.

За клиенти, които оперират с една валута или само с част от „n‟, конфигурирана в системата, части от правилото се пропускат или не. Например: ако системата е конфигурирана да работи с CUC и CUP и искате клиентът да плати 98% от CUC компонента, трябва да бъде написано следното правило:

CUC * 98/100;

След като правилата са дефинирани, системата е в състояние да ги оцени за удостоверени клиенти по такъв начин, че е възможно клиент "X" и друг "Y" да посещават продукт в унисон и да виждат различни цени поради правилата, които се прилагат.

С описаното досега е възможно системата да формулира цени и суми според клиентите, които разглеждат страниците му, но как се извършва плащането?

Когато клиентът има продуктите, които иска да закупи в своята „пазарска количка“, той може да отпечата съдържанието или да се обърне към формуляра за плащане, където ще се събират данните от кредитната карта за всяка от сметките, свързани с валутите, в които се използват. прави продажбата. По желание можете да определите получател за покупката, като в този случай ще се изискват нови данни и общата цена ще бъде преоценена, като се вземе предвид разстоянието на доставка.

Онлайн услуга

Като добавена стойност в системата е включен онлайн път за обслужване. За да направите това, в подробните изгледи на продуктите е проектирана опцията с това име, с която клиентите могат да показват чат панел и да се свържат с длъжностно лице, отговарящо за участието в тези заявки, или други клиенти, които разглеждат сайта. По този начин се насърчава среда за обмен на търговска информация за продуктите и опит от тяхната употреба между длъжностни лица и клиенти.

За да се избегне злоупотреба с тази опция, трябва да бъде приложен речник на думите „не е позволено“ и както длъжностните лица, отговарящи за разглеждането на тези искания, така и законните администратори да гарантират целостта на изпратеното чрез деактивиране на достъпа на нарушителите. под санкция на търговски мерки, добавени като клаузи към договора.

Изграждане на предлаганото решение

Принципи на дизайна на приложението

7-те принципа на универсалния дизайн се съсредоточават върху дизайна, който може да се използва универсално или от всички, но трябва да се вземе предвид, че други аспекти се намесват в дизайна, като например разходите, културата, в която ще се използва, околната среда; това също не може да бъде забравено. Тези Общи принципи на дизайна са приложими и в действителност се прилагат в архитектурата, инженерството и, разбира се, уеб страниците и приложенията, наред с други области на приложение.

1-ви принцип: еквивалентна употреба

Дизайнът е полезен и продаваем на хора с различни способности.

Насоки за принцип 1:

Осигурете едни и същи начини на използване за всички потребители: идентични, когато е възможно, еквивалентни, когато не е. Избягвайте сегрегиране или стигматизиране на всеки потребител. Функциите за поверителност, гаранция и сигурност трябва да бъдат еднакво достъпни за всички потребители. дизайнът е привлекателен за всички потребители.

Втори принцип: Гъвкаво използване

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

Насоки за принцип 2

Това предлага възможности за избор в начините на употреба, че може да се получи достъп и да се използва както с дясната, така и с лявата ръка.Това улеснява потребителя с точност и прецизност. ü Това се адаптира към темпото или ритъма на потребителя.

3-ти принцип: Прост и интуитивен

Използването на дизайна е лесно за разбиране, в зависимост от текущия опит, знания, езикови умения или степен на концентрация на потребителя.

Насоки за принцип 3

Това елиминира излишната сложност, което е в съответствие с очакванията и интуицията на потребителя.

Това включва широк спектър от грамотни и езикови умения.

Разпространявайте информацията в съответствие с нейното значение Предоставете ефективни подсказки и методи за отговор по време и след приключване на задачата.

Четвърти принцип: възприемчива информация

Дизайнът ефективно съобщава необходимата информация на потребителя, като взема предвид условията на околната среда или сензорните възможности на потребителя.

Насоки за принцип 4

Използвайте различни режими, за да представите излишно основната информация (графично, устно или тактилно) Осигурете достатъчен контраст между съществената информация и нейното обкръжение. Разширете четливостта на съществената информация. (например улеснявайте даването на указания или указания). Осигурете съвместимост с различни техники или устройства, използвани от хора със сензорни ограничения.

Пети принцип: Толерантен към грешка

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

Насоки за принцип 5

Това има елементи за минимизиране на рисковете и грешките: елементи, които се използват повече, по-достъпни; и опасни елементи, отстранени, изолирани или покрити. Предоставяйте предупреждения за опасности и грешки. Осигурете характеристики за безопасно изключване. Обезсърчете несъзнателните действия при задачи, които изискват бдителност.

Шести принцип: Това изисква малко физически усилия

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

Насоки за принцип 6

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

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

7-ми Принцип: Размер и пространство за достъп и употреба

Осигурете подходящ размер и пространство за достъп, обхват, манипулация и употреба, като вземете предвид размера на тялото, стойката или мобилността на потребителя.

Насоки за принцип 7

Осигурете ясна видимост на важните елементи както за седнал, така и за стоящ потребител.Достъпът на всеки компонент е удобен за всеки седящ или стоящ потребител.Подхожда на вариации в размера на ръката или захвата. Осигуряване на пространство, необходимо за използване на технически средства или лична помощ.

Дизайнът трябва да се основава на смесицата от идеи, желания и нужди на потребителя и на материалите, достъпни за програмиста, и в този случай става дума за потребители, които могат да бъдат експерти или неопитни в темата; някои от тях неподготвени по въпросите на ИТ.

За тази цел тази система използва определени общи принципи, които гарантират използваемост в дизайна за тези приложения:

Интерфейсът не трябва да претоварва потребителя с ненужни сложности или да го разсейва от работата му. На потребителя трябва да му бъде предоставена гъвкава среда, за да може бързо да се научи да използва приложението, когато се предлагат опции в методите на употреба, което улеснява потребителя точност и прецизност и се приспособява към темпото или темпото на потребителя. Интерфейсът трябва да е последователен. Производителността на потребителя трябва да се вземе предвид преди производителността на машината. Ако потребителят трябва да изчака отговора на системата за дълъг период от време, тези загуби на време могат да се превърнат във финансови загуби за организацията. Помощните съобщения трябва да са прости и да дават отговори на проблеми. Етикетите на менютата и бутоните трябва да съдържат ключовите думи за процеса, а интерфейсът трябва да има обратими действия.

При разработването на интерфейса на това приложение бяха взети предвид горните принципи, както следва:

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

Характерни елементи бяха използвани за описанието на действията, както изображения, така и текстове.

Приложението показва съответствие с физиологичните изисквания по отношение на човека при получаване на цифрова информация, така че тяхното здраве да не се влияе от неправилна употреба, например: размер на шрифта, разстояние между знаците, типография, контрастна цифра - предистория на информацията за мнозинството, стандартизация на маржовете и разпределение на информацията в целия софтуер.

Лечение на изключенията

Жизнено важно е да се постигне правилната работа на всяка система, за да се идентифицират и контролират възможните грешки, които могат да възникнат при взаимодействие със софтуера. За правилната работа на приложението тези грешки ще бъдат третирани по такъв начин, че взаимодействията с базата данни (вмъкване, изтриване, модификация…) да се извършват правилно, за да се постигне това, бяха създадени механизми за валидиране, които проверяват верността на данни за обработка; Освен това формулярите настояват потребителят да въведе възможно най-малкото количество данни, като се възползва максимално от изчислимите полета във формата, контроли за избор; като: радио бутони (RadioButton), квадратчета за отметки (CheckBox) и списъци за избор (ListBox), между другото.По този начин потребителят избира между предварително зададени опции, което не оставя място за грешка.

В случай на въвеждане на данни от потребителя, съоръженията, предоставени от C # и ASP.NET, се използват за проверка на данните; ако има грешки, се показват съобщения, които илюстрират неправилното вмъкване, промяна или лошо манипулиране на данни като цяло с възможностите, предлагани от използвания език, показвайки на потребителя правилна и обяснителна информация за възможната грешка. Всички съобщения за грешки се показват в маркирани съобщения, използващи средствата на AJAX технологията за изпълнение на функциите, отговарящи за контрола и валидирането на данните в клиента, и ще бъде реализирана втора валидиране на данните, изпратени от потребителя и получени от клиента. базата данни, за да се сведе до минимум възможните грешки и да се гарантира, че потребителят взаимодейства със система за качество.

Стандарт за кодиране

„Всеки глупак може да напише код, който компютрите разбират. Добрите програмисти пишат код, който хората разбират. " Мартин Фаулър

Стандартът за кодиране се фокусира върху ръководствата за стил за програмиране на езика C #, въпреки че може да се използва в много други езици и среди, за да се установят условностите, които да се използват.

Организация на файлове
- Изходни файлове

Всеки клас трябва да бъде в един файл и файл не може да съдържа повече от един клас. Въпреки че във файл, заедно с неговия клас, могат да бъдат определени свързаните елементи, например изключенията, които той може да хвърли.

Дърво на директории и пространство от имена

Пространството на имената на обектите ще бъде отразено в дървовата директория на изходния код. По този начин класът Y10K.AyeAye.Switch ще има своя код в Y10K / AyeAye / Switch.cs. Ако абстрактен клас съдържа полезен код и други класове наследяват от него, като класове за специализация, ще има файл с разширение cs, съответстващ на абстрактния клас и на същото ниво директория с името на абстрактния клас, който ще съдържа класове по наследяване.

вдлъбнатина
- Дължина на линията

Дължината на реда няма да бъде по-голяма от 80 знака, когато е възможно.

Разделени линии - Всеки път, когато линия трябва да бъде разделена на две, ще се използват следните конвенции:

Ако има списък с елементи, разделени със запетаи, той ще бъде разделен след запетая.

Ако е израз, той ще бъде разделен след един от операторите. За предпочитане, изразът ще бъде разделен на по-високи нива, а не по-ниски нива.

Разделената линия ще бъде подравнена с нивото, в което е станало разделянето.

Разстояния на отстъп

Като се има предвид различието в броя на отстъпите, ще се използват раздели, които могат да бъдат използвани с много редактори, които да бъдат представени с различни количества интервали и най-вече те да се превърнат в щракване на отстъп.

Декларациите
- Брой извлечения на ред

По дефиниция същият ред никога няма да бъде използван за повече от едно определение, което улеснява коментарите относно декларирания елемент.

Инициализация

Когато е възможно, променливите ще бъдат инициализирани в един и същ ред на декларация

Декларация за класове и интерфейси: За да дефинирате класовете и интерфейсите, ще се следват следните правила:

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

Отварящата скоба, която съдържа кода, се записва сама на реда следвайки определението на прототипа. По същия начин съответната затваряща скоба се записва сама на последния ред.

Изречения
- Прости изявления

Всеки ред ще съдържа не повече от едно изречение, въпреки че, както е обяснено в раздел 3, изречението може да бъде на повече от един ред

Декларации за връщане

Декларацията за връщане не използва скоби.

Основен оператор за избор (ако / ако… друго / ако… друго, ако… друго)

Началните скоби на кодов блок се поставят в края на оператора if, else или else if. Затварящите скоби са на отделни линии. Когато друго или друго, ако оператор следва блок от код, операторът ще бъде поставен на същия ред като затварящата скоба.

За или предсказвайте изявления за контур

Подобно на операторите за избор, скобата с отворен блок ще бъде поставена след декларацията за дефиниция на for или foreach, а затварящата скоба на отделен ред.

Докато или правите, докато циклични изявления

Идентичен за, но в случай на „да“, докато времето ще бъде поставено на същата линия като последната скоба.

Избор на няколко избора (превключвател)

По отношение на ключовете, те ще бъдат поставени както в останалите случаи. По отношение на кода и линията на прекъсване, те ще преминат с един отстъп повече от съответния ред, който ще отиде с един отстъп повече от превключващата линия.

Извлечения за извличане и обработка на изключение (опитайте / улавете / най-накрая) Боравенето с блокови клавиши ще бъде както в останалите отчети.

Заготовки
- Празни линии: празните линии могат да се използват за разделяне на групи от линии, които имат определена логическа връзка. Два празни реда в един ред се използват за:

Отделни секции от код във файл.

Отделни дефиниции за клас и интерфейс във файла.

Празен ред отделя…

Методи.

Дефиниции на локални променливи в метода. Кодови блокове, които не са пряко свързани.

Разделения между термините

В списъка с параметри интервалите ще бъдат поставени след запетаи, но никога след скобите или преди. В заданията интервалите ще бъдат поставени преди и след =. В изразите интервалите ще се използват само когато е строго необходимо и да се разделят различните изрази.

Разделения в декларации

Ще бъде направен опит за поддържане на таблична структура за променливите линии на деклариране, така че да се чете информацията лесно. В следващия пример можете да видите как да поддържате тази структура, но имайте предвид, че за интервали трябва да използвате интервали, а не раздели:

string name = "Mr. Ед ”; int myValue = 5;

Test aTest = Test.TestYou;

Номенклатура: Важно е да се има предвид, че унгарската нотация няма да бъде използвана за абсолютно нищо, с изключение на кодирането на GUI, където може да се използва, но детайлно видовете в подробни наставки (cancelButton, например).
- Номенклатура за часовете

Името на клас трябва да се състои от съществителни имена. Ще се използва капитализация на Паскал. Няма да се използва префикс за клас.

Номенклатура за интерфейси

Те ще бъдат назовавани с съществителни или прилагателни, които описват поведението. Капитализация Паскал. Те са с префикс I, с главни букви, а думата, която следва, също е с главни букви.

Номенклатура за изброяване

Pascal ще се използва както за имена на стойности, така и за имена на типове. Нито префиксите, нито наставките няма да бъдат използвани. Ще се използват единични съществителни имена

Номенклатура за константи и атрибути само за четене Pascal ще се използва с съществителни или съкращения на съществителни Номенклатура за нормални параметри и атрибути

Ще бъдат използвани описателни имена, подчертаващи значението преди типологията на параметъра. В този случай се използва капитализация на камили.

Номенклатура за променливи

Камилата ще се използва. Когато се използват тривиални броячи, ще се използват имена като i, j, k, m, n,…

Номенклатура за методите

Методите ще бъдат именувани с глаголи, в Pascal.

Номенклатура за имоти Номенклатурите ще бъдат използвани, в номенклатурата на Паскал за събития

Събитията ще бъдат суфиксирани с EventHandler и ще бъдат използвани два параметъра, наречени изпращач и e. Ще се използва Pascal. Глаголите ще бъдат използвани в минали и настоящи времена, за да дадат представа за смисъла на събитието.

Практики на програмиране
- видимост

За предпочитане атрибутите клас и екземпляр ще бъдат кодирани като частни, така че да има методи на аксесоар.

Магията е забранена

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

Коментари

Ще се използва само // формат, / *… * / никога няма да бъде използван.

Когато трябва да се коментира блок от редове, толкова много // в началото на реда ще бъдат използвани, сякаш това е # в скрипт с черупки.

Помощ Концепция

Имайки предвид, че всички потребители, които ще работят с приложението, не са напреднали и може да имат малък или никакъв опит с приложението, възниква необходимостта да им се покаже помощта, което ще им позволи да знаят работата на всяка от системните опции, За това ще бъдат приложени няколко механизма, които позволяват на потребителя да бъде информиран и ориентиран по всяко време, следователно във всеки интерфейс ще има опция за помощ с описанието на всяко поле и опциите на този интерфейс, което ще им позволи да знаят какво да правят. и какви данни да въведете по всяко време.

Оценка на устойчивостта

Административно въздействие

Развитието на уеб системата не изисква прекомерни ресурси, с използването на не толкова напреднал компютър, принадлежащ към петото поколение микрокомпютри с най-използваните операционни системи и използването на някои безплатни софтуер за разпространение, може да се постигне стабилна версия в няколко месеца.

За да видите сайта, не са необходими толкова напреднали условия: компютър Pentium III с уеб браузър (Internet Explorer, Mozilla Firefox, Opera), 64 MB оперативна памет и връзка с мрежата, където е публикуван „HostingService“, което може да бъде LAN, Интранет или Интернет. Ако искате да внедрите приложението в оптимални условия, можете да използвате съвременни технологии, които биха довели до следните разходи (Хардуер за мрежа. Цени, осигурени от Copextel Corporation):

Количество Описание	Цена (CUC)
един	DELL PE830 сървър 3GHZ / 2MB / 800 / 512MB / 2X73GB / M / K	2,177.80
един	DELL E173FP цифров монитор с плосък панел 17 ”	299,00
един	Стенен шкаф 2 cpo 12U стъкло	239,89
един	AT-8024-10. 24 порта 10/100 база TX, слой 2, мениджър	424,84
един	Zyxel ES-1024A Fast Ethernet Switch 24 × 10/100 Base Tx	129,04
3. 4	Пач корд 3м	81.94
14	DEXSON Канал 60 × 40 (2 м)	68.04

Създаването на системата насърчава нови начини за дистрибуция на продукти (или услуги), увеличаване на възможностите за бизнес, като се отчита увеличението на потенциалните клиенти от всеки географски район без ограничения. По същия начин се постига отваряне и разширяване към нови отдалечени и / или непознати пазари, а работните часове на услугата се увеличават максимално от "n" часа на ден до предлагането на услугата 360 дни в годината, 24 часа на ден.

Внедряването на системата не изисква физическо присъствие на персонала, като по този начин се намаляват разходите, използвани за поддръжката и заплащането на тези служители. Той също така повишава повишението на удовлетвореността на клиентите, като разполага с удобен, бърз и лесен начин за връзка с бизнеса: Не е необходимо да чакат телефонът да бъде отговорен, да се преместят в магазина си, да предлагат, консултират и купуват с ограничение на времето…

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

софтуер	Цена (USD)
Вариант на безплатен софтуер
Kubuntu 7.10 Gusty	Безплатно
MonoDevelop	Безплатно
Уеб сървър на Apache	Безплатно
PostgreeSQL база данни сървър 8.2.4.1	Безплатно
Вариант с патентован софтуер
Уиндоус експи	$ 128,00 - 307,53 долара
Visual Web Developer 2005 (Експресно издание)	Безплатно
Интернет информационен сървър	Включени в ОС
SQL Server 2005 (Експресно издание)	Безплатно

Социално-хуманистично въздействие

Системата не накърнява качеството на живота на обществото по никакъв начин, напротив, представлява принос за компютъризирането на обществото и надежден и актуализиран източник на информация и пазар, чрез който регистрираните лица могат да правят своите покупки онлайн.

Достъпа до системата може да бъде отвсякъде с достъп до мрежата, където е публикувана, така че нейното ниво на генерализация е променливо, тъй като може да бъде от малка локална мрежа до Интернет

Внедряването на сайта генерира няколко работни места: компютърен инженер, отговарящ за управлението на услугите, предоставяни от сайта, който ще осигури неговата поддръжка и правилна работа; търговски администратор и юридически администратор, които трябва да са завършили специалности, свързани с функцията, която изпълняват.

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

Влияние върху околната среда

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

Интерфейсът се характеризира с извити и гладки функции, което предава усещане за спокойствие и спокойствие, а поради използването на AJAX се използват фини анимации, плавни преходи, без излишна информация и избягва психологически стрес за потребителите.

Технологично въздействие

За да използвате приложението, не са необходими съвременни компютърни познания, напротив, изискват се само основни познания за това как да се манипулира уеб страница в браузъра; също имат минимални представи за сърфиране в Интернет, за да имат достъп до различните модули за информация, продажби и конфигурация на системата. За администрирането на сайта не се изискват и съвременни познания, само основни принципи, овладяване на различните модули и притежаване на средни познания за клиент-сървърната технология (управление на уеб сървър и система за управление на база данни).

Организацията, която приема сайта, може да бъде напълно независима от производителя, което позволява, според социалното му въздействие, имплантирането на сайта на други места, без да е необходимо присъствието на производителя или създателя на сайта.

Сред технологичните фактори, които представляват риск от уязвимост, са повреда или неизправност на сървъра, в който е хоствано приложението, повреда на оборудването на цифрови комуникационни канали (мрежови кабели, комутатори, концентратори и др.). Всичко това може да се избегне, като се спазват мерките за компютърна сигурност и се прилага периодична поддръжка на хардуера и софтуера, с които разполага организацията.

Приложението има възможност за адаптиране към бъдещи промени, поради архитектурата, ориентирана към n-ярусни услуги, които се зареждат динамично и могат да се актуализират както динамично, така и ръчно, без приложението да представя грешки или неизправности в работата му.

Заключения

В резултат на изследването се открояват следните заключения:

Разработен е инструмент, който осъществява процесите на електронна търговия на едро в съответствие с наредбите, установени за Куба. Извършен е преглед на съществуващата библиография, за да се знае произхода и развитието на електронната търговия и степента на новост на резултатите от тази работа. разработи проектирането, внедряването и тестването на получената в резултат на това система за управление на продажбите на едро. Методологията, използвана за проектиране и разработване на приложението, беше ефективна и е достъпна за използване в подобни системи. технологичен и екологичен процес на разработване на системата за управление на продажбите на едро на продукти, може да се каже, че този продукт е устойчив.

препоръки

Препоръчва се въз основа на резултата от разследването:

Внедряването и използването на системата в МСП в страната за оценка на нейното внедряване в по-голям мащаб. Използването на системата като помощен материал за преподаване на теми като "Електронна търговия" и незадължителни курсове като "Архитектура и модели". Разработване на нови версии, които се впускат в Използване на други методологии като RUP или XP, за да направите сравнение на получените резултати Направете общата миграция на системата към платформи, гарантиращи нейната технологична независимост.

библиография

Защо ASP.NET? Esquivel, Хулио Батиста. 2006. 4, Мадрид: сн, 2006, том 1. Алмейда. 2002. Буфет Алмейда. Уебсайт на Bufet Almeida 12 октомври 2002 г. http://www.lssice.com/23/lssice. Алварес, Мигел Ангел. 2006. Уеб разработка. 2006. http://www.desarrolloweb.com/php/. Аравена I, Диего и други. 2006. Електронна търговия. Педагогически факултет, Универсидад де ла Фронтера. Temuco: sn, 2006. Arsys. 2007. Arsys.es. Помощен уебсайт: хостинг ресурси, електронна търговия. http://www.arsys.es/ayuda/directorio/productos/hosting/comercio-electronico.htm. Сътрудници, Anguiano &. 2006. Правни проблеми на електронната търговия. Испания: sn, 2006.AUKEN, J. 2007. HTTP транзакции с използване на PHP. 2007.http: //www.malditainternet.com/node/63? PHPSESSID = d7825b7a5b5ca2adea79bd0505c09db Авила, Едуардо Рене Родригес. 2008. Електронна търговия. Секция за следдипломни изследвания и изследвания, УПИИЦА. 2008. БАНКИНГ, CDS 2006. Други банкови операции: събиране и плащане. 2006. http://www1.euskadi.net/guiaconsumo/curso_bancario/preguntas.apl?apartado=26. Bitpipe. 2004. Bitpipe.com. 2004. http://www.bitpipe.com/tlist/Perl.html. BORETTO, MM 2005. Аспекти на интелектуалната собственост, извлечена от дигиталната среда, в международното частно право. 2005. http://www.eumed.net/libros/2005/mmb/index.htm. Броса, Педро. 2000 година.Бизнес стратегии и правни и данъчни последици. 2000. CAMPITELLI, ADRIÁN. 2003. Електронна търговия. 2003. http://www.monografias.com/trabajos12/monogrr/monogrr.shtml. CARAMÉS, HV 2006. Банки в Интернет. 2006. http://www.ciao.es/Opiniones/PayPal__289916. КОМУНИКАЦИИ, ГД 2007. 2007. http://www.dimensis.com/pasarela-de-pagos.html. Corporation, Microsoft. 2005. Преглед на продукта на SQL Server 2005. Технически център на Microsoft SQL Server. 2005. -. 2007. Архитектурният вестник. 2007. Cuervo, José. 2008. Субектите за цифрово подписване и сертифициране. 2008.http: //www.informatica-juridica.com/trabajos/firma_digital.asp.DILOCONFORES. 2006. Сигурни транзакции, форми на плащане. 2006. http://diloconflores.com/store/comersus_index.asp. Обясняване на Scrum след 10 минути. Серано, Хорхе. 2007. 4, Богота: сн, 2007, том 1. Естенос, Раул Санчес. 2005. 10 причини за използване на Java. Lima: sn, 2005. FERNÁNDEZ, F. 2007. Уеб програмиране: Използвани езици. 2007.http: //www.xeoweb.com/programacion-web.php. Гомес, Расиел. 2001. Интернет маркетинг. Раул Порто Сантос. Lima: sn, 2001. GUARDIA, CDL 2007. Еволюцията на електронната търговия. 2007.http: //www.razonypalabra.org.mx/anteriores/n20/20_cguardia.html. Ерера, Йохани. 2007.Техники и инструменти, използвани в проектирането на изисквания. 2007. http://www.monografias.com/trabajos6/resof/resof2.shtml.. ITAA. 2004. Американската асоциация за информационни технологии. 2004. www.itaa.org. MARAÑÓN, G. Á. 2008. Сигурни електронни транзакции (SET), начин на плащане. 2008. http://www.iec.csic.es/criptonomicon/comercio/set.html. MENDEZ, J. 2006. Тенденции в езиците за програмиране. 2006. http://www.monografias.com/trabajos/tendprog/tendprog.shtml. Microsoft. 2006. Електронният подпис и надеждността на онлайн транзакциите. 2006. http://www.microsoft.com/spain/seguridad/xp/firma/default.asp. NEWKIRK, J. 2002.Екстремно програмиране на практика. Мадрид: sn, 2002. Правни новини. Правни новини 2000. http: //noticias.juridicas.com.Planeta Code. 2005. http://www.planetacodigo.com/wiki/glosario:extreme_programming. Pressman, Roger S. 2002. Софтуерно инженерство. Практически подход. 2002. REBELDE, MECD 2005. Пречка за електронната търговия. 2005. http://www.mesaredonda.cu/informacion.asp?idInformacion=254&idSeccion=4&Logo=71. Рибас, Ксавие. 2005. ЕЛЕКТРОННИ, ПРАВНИ АСПЕКТИ НА ТЪРГОВИЯТА. 2005. Родригес, Хавиер Пренафета. 2005 година.Хостинг договори. Преглед на основните проблеми, които трябва да бъдат взети под внимание при договаряне на този вид договор “на уебсайта на Асоциацията за насърчаване на информационните технологии и електронната търговия (APT. 2005. http: // news. juridicas.com/external/nj_aptice/2002085556141710242121.html Russo, Renne 2001. Информационни и комуникационни технологии. 4, 2001, том 1. Saldivar, Raul Vicente. 2007. 5 причини да не се използва Spring.: sn, 2007. 2. Schwaber, Ken and Beedle, Mike 2003. Разработка на Agile Software с SCRUM 2003. Компютърна сигурност, защо и за какво. 2002. Ноември 2002, RED. Serrano, Agustín 2006.Правна и фискална рамка в електронната търговия. 2006. Simsom, Ричард. 2007. Компютърна сигурност. Общността на експертите в мрежа. 2007. Спаркссистеми. 2005. 2005. www.sparxsystems.com. STEPHENS, M., ROSENBERG, D. 2003. Екстремно програмиране, възстановено: делото срещу XP California: sn, 2003. Takeuchi, Hirotaka. 1999. Scrum. 1999. Варея, Исмаел Гарсия. 2006. JAVA Пристанище за експерти? 14 от 4 от 2006 г.

приложения

Приложение 1: Преглед на виртуалния магазин

Приложение 2: Преглед на сайта на администрацията

Приложение 3: Основни функции на системата за електронна търговия.

Достъпът е ограничен до потребителите с код за достъп. Публичен и частен каталог на продуктите. Отпечатване на каталози. Състояние на поръчката и проследяване. Управление и ситуация на рискове, връщания и колекции. Търсач на артикули. Виртуален магазин. Наличност на артикули по опции (цветове, размери, трайност и т.н.). Криптиране на данни и поръчки. История на фактуриране. Доставка на поръчки. Печат на фактури. Утвърждаване на плащанията чрез SSL защитени страници и онлайн банка. Конфигурируем файл на артикула. Конфигурируема форма за покупка.Импортиране на статии от други бази данни. Резервно копие. Включени шаблони за дизайн. Офлайн поддръжка. Поръчка на избрани продукти. Редактиране на страници във визуален WYSIWYG формат.

Речник на термините

Области за продажби на едро: онези анклави в единици за търговия на дребно, производство или обслужване, които продукти или услуги на едро предварително одобрени в тяхната политика за търговия на едро. Краен клиент на едро: физическо лице, работник в една от компаниите, органите или организациите на централната държавна администрация, с които е подписан Договорът за продажба на модули и изрично е регистриран в договора. Търговия на едро: Нарича се търговия на едро или на едро, продажбата на национално произведени или вносни стоки, предназначени за търговци на дребно, промишлени и институционални потребители и търговци на едро, наред с други. В този магазин можете да извършвате и продажби на дребно. Купувач: Юридическо лице, с което са установени задълженията, свързани със Закона за продажба чрез договор. МСП: Малки (и) и средни (и) фирми. Търговски единици на дребно(Комерсиализация на модули), са единици, предназначени за търговия на едро на продукти, предвидени в асортиментната политика на звеното с този вид продажби, предназначени за дружествата, органите и организациите на Централната държавна администрация и чиято доставка се извършва подробно до крайния клиент. Този тип продажби ще се извършват само в Специализирани единици за този тип продажби на едро. Единици на едро: Устройствата, определени в разходен център, се наричат единици за продажби на едро, където се извършва търговия на едро на продуктите или услугите, одобрени в неговата Асортиментна политика. продавач: Звено за продажба на едро или зона на дружеството, упълномощено от тази процедура да извършва продажби на едро на юридическите лица, предвидени в тази процедура

Планиране на ресурсите на предприятието

Прост протокол за достъп до обект. Това е стандартен протокол, създаден от Microsoft, IBM и други, понастоящем той е под егидата на W3C, който определя как два обекта в различни процеси могат да комуникират чрез обмен на XML данни.

Изтеглете оригиналния файл