Especificacions, anàlisi i disseny d'un programari de ...openaccess.uoc.edu/webapps/o2/bitstream/10609/75685/6... · dissenya un sistema anomenat TPV2.0 per a gestionar terminals

TFC – Enginyeria del ProgramariEnginyeria Tècnica Informàtica de GestióUniversitat Oberta de Catalunya

Especificacions, Anàlisi i Disseny d'un Programari de Gestió de Punt de Venda

Autor: Manel Orós Cuenca

Enginyeria Tècnica Informàtica de Gestió

Consultor: Oriol Martí Girona

09/01/2009

Manel Orós Cuenca Pàgina 1 de 97


1 Dedicatòria i agraïmentsMitjançant aquest treball es condensa tot un procés d'il∙lusions i superació personal que al llarg de la carrera s'ha anat gestant, algunes vegades en forma de frustració i d'altres, les que més, en forma de bones estones.Durant aquest llarg i a vegades difícil procés hi ha hagut unes persones que sempre, de forma incondicional, han estat al costat meu i és a aquestes a les que voldria dedicar aquest treball i, per extensió, tota la carrera: a la meva dona Marisol, a la meva filla Alba i a la meva mare Lola. També a algunes altres persones properes a les anteriors que han estat sempre quan les he necessitat. A totes elles els vull dedicar també aquest escrit.Finalment, agrair també a tota una infinitat de persones el fet de posar en xarxa tot el seu coneixement, enginy, esforç i creativitat de forma altruista perquè estudiants com jo puguem aprendre dels fòrums on participen, dels seus blogs i també puguem utilitzar les seves eines i sistemes operatius lliures i de codi obert per desenvolupar el nostre TFC i, més àmpliament, la nostra carrera. A tots, gràcies de veritat.



2 ResumAquest TFC gira entorn a un projecte que recull els requisits, analitza i posteriorment dissenya un sistema anomenat TPV2.0 per a gestionar terminals punt de venda.A la primera fase del treball es defineixen les condicions de l'estudi de l'eina TPV2.0, les quals ocorren sobre l'escenari d'una empresa client anomenada Kobrabo, dedicada a la distribució al detall de productes alimentaris, que sol∙licita un projecte de millora en profunditat del seu sistema de cobrament mitjançant els seus terminals punts de venda (TPV) que en l'actualitat pateixen una notable obsolescència.A la segona fase de l'estudi, la fase d'anàlisi i recollida de requeriments, el client posen de manifest una sèrie de necessitats que es recopilen en forma textual i de casos d'ús i que donen les primeres pautes per a iniciar el procés d'anàlisi. Entre aquests requeriments consten la necessitat d'estandarditzar la plataforma de cobrament, agilitzar els processos amb el client, ferlos mes segurs o facilitar el procés d'aprenentatge. També, en aquesta fase, es fa un primer apropament a les classes d'entitat i les seves característiques principals, que finalment han d'esdevenir classes de negoci per a definir la futura funcionalitat.A la fase final del TFC, la fase de disseny, es defineix amb tota la exactitud possible com es portarà a terme la persistència mitjançant diagrames E/R (entitat/relació) i mitjançant les taules del model relacional. Tanmateix, es defineix també la funcionalitat de l'eina TPV2.0 mitjançant la utilització de diagrames estàtics de classes d'entitat, diagrames dinàmics d'interacció i de seqüència i prototipus de la interfície gràfica d'usuari.L'àmbit del treball finalitza aquí, a la fase de disseny, per motius de calendari i es deixen les etapes posteriors com la implementació o el desplegament per a una segona revisió del treball.



Índex de continguts 1 Dedicatòria i agraïments........................................................................................................................2 2 Resum....................................................................................................................................................3 3 Introducció.............................................................................................................................................8

3.1 Situació actual................................................................................................................................8 3.2 Àmbit i objectius del TFC...........................................................................................................10 3.3 Exclusions....................................................................................................................................10 3.4 Anàlisi de riscos...........................................................................................................................11 3.5 Metodologia.................................................................................................................................11 3.6 Tasques a executar.......................................................................................................................12

3.6.1 Diagrama Gantt del pla de treball, planificació i dates clau...............................................13 4 Fase d'anàlisi i requisits.......................................................................................................................14

4.1 El model de negoci.......................................................................................................................14 4.2 Guió general d'un punt de venda actual.......................................................................................16 4.3 Guions importants del futur sistema............................................................................................18

4.3.1 Obertura de caixa.................................................................................................................18 4.3.2 Tancament de caixa..............................................................................................................18 4.3.3 Guió de cobrament d'articles...............................................................................................18 4.3.4 Guió de pagament amb tarja de crèdit.................................................................................19 4.3.5 Guió de pagament amb efectiu............................................................................................19

4.4 Algunes característiques del model de negoci............................................................................19 4.4.1 Actualització de preus a la botiga........................................................................................19 4.4.2 Els impostos i els descomptes.............................................................................................20 4.4.3 Senyalització de preus.........................................................................................................20 4.4.4 Eliminació d'informació.......................................................................................................21 4.4.5 Cicle de vida de la botiga.....................................................................................................21 4.4.6 Pèrdua desconeguda.............................................................................................................21 4.4.7 Tancament a Zero.................................................................................................................22 4.4.8 Nivells de prioritat del sistema............................................................................................22 4.4.9 Codi d'article intern envers codi EAN.................................................................................23

4.5 Requeriments no funcionals per al nou sistema..........................................................................24 4.5.1 El control del calaix portamonedes.....................................................................................26 4.5.2 La tecla del pànic.................................................................................................................26 4.5.3 Les promocions....................................................................................................................27



4.5.4 L'agent TEF..........................................................................................................................28 4.6 Actors...........................................................................................................................................29

4.6.1 Actors principals..................................................................................................................30 4.6.2 Actors de recolzament.........................................................................................................30 4.6.3 Diagrama de casos d'ús actor Encarregat............................................................................30 4.6.4 Diagrama de casos d'ús actors Caixer, Client, Empleat i TEF............................................31 4.6.5 Diagrama de casos d'ús actor Timer i Central.....................................................................32

4.7 Classes de negoci: Atributs i relacions principals......................................................................33 4.7.1 Persistència de les dades......................................................................................................35

4.7.1.1 Nivell local....................................................................................................................36 4.7.1.2 Nivell intermediari o caixa central...............................................................................36 4.7.1.3 Nivell remot..................................................................................................................36

4.8 Subsistemes del model de negoci................................................................................................37 4.9 Subsistema de comunicacions.....................................................................................................38

4.9.1 Concurrència de les dades...................................................................................................39 4.9.2 Activació dels processos de comunicacions........................................................................39 4.9.3 Cas d'ús Enviar Pendents a Central.....................................................................................40 4.9.4 Cas d'ús Enviar Pendents a Botigues...................................................................................41 4.9.5 Cas d'ús Activació de Canvis...............................................................................................42 4.9.6 Cas d'ús Confirmació d'Enviaments....................................................................................42

4.10 Subsistema de cobrament...........................................................................................................43 4.10.1 Cas d'ús Enregistrar un Article...........................................................................................43 4.10.2 Cas d'ús Iniciar un Tiquet..................................................................................................44 4.10.3 Cas d'ús Totalitzar un Tiquet..............................................................................................45 4.10.4 Cas d'ús Tancar Transacció................................................................................................46 4.10.5 Cas d'ús Devolució d'Articles............................................................................................47 4.10.6 Cas d'ús Rectificar Línies de Tiquet..................................................................................49 4.10.7 Cas d'ús Cobrament TEF...................................................................................................49 4.10.8 Cas d'ús Pagament de Caixa...............................................................................................50

4.11 Subsistema de seguretat i manteniment.....................................................................................51 4.11.1 Cas d'ús Alta d'Usuari.........................................................................................................52 4.11.2 Cas d'ús Baixa d'Usuari......................................................................................................52 4.11.3 Cas d'ús Modificació d'Usuari...........................................................................................53 4.11.4 Cas d'ús Iniciar Sessió........................................................................................................54 4.11.5 Cas d'ús Renovar contrasenya............................................................................................54 4.11.6 Cas d'ús Bloqueig de Caixa................................................................................................55 4.11.7 Cas d'ús Finalitzar Sessió...................................................................................................55

4.12 Subsistema de control de caixa..................................................................................................56



4.12.1 Cas d'ús Informar d'Efectiu................................................................................................56 4.12.2 Caso d'ús Arqueig de Caixa...............................................................................................57 4.12.3 Caso d'ús Tancament de Caixa...........................................................................................58 4.12.4 Caso d'ús Inici de Dia........................................................................................................58 4.12.5 Cas d'ús Retirada d'Efectiu.................................................................................................59 4.12.6 La gestió de perifèrics........................................................................................................60 4.12.7 Cas d'ús Llegir un EAN.....................................................................................................60

4.13 La interfície d'usuari ..................................................................................................................61 4.13.1 Teclat físic amb tecles directes...........................................................................................61 4.13.2 Pantalla tàctil......................................................................................................................62 4.13.3 Sistema auditiu...................................................................................................................63

5 Fase de disseny....................................................................................................................................65 5.1 Disseny de la persistència............................................................................................................65

5.1.1 Diagrama del model E/R......................................................................................................65 5.1.2 Transformació del model E/R al model relacional..............................................................66

5.2 Diagrames estàtics.......................................................................................................................67 5.2.1 Diagrama estàtic de classes.................................................................................................68 5.2.2 Detall de les classes d'entitat mes representatives..............................................................69 5.2.3 Diagrama de classes d'Excepcions......................................................................................70 5.2.4 Diagrama de classes d'Interfície d'Usuari...........................................................................70 5.2.6 Diagrama de classes de Persistència....................................................................................71

5.2.6.1 Gestió del nivell de persistència...................................................................................72 5.3 Diagrames dinàmics....................................................................................................................73

5.3.1 Diagrama de seqüència Alta d'Usuari.................................................................................73 5.3.2 Diagrama de seqüència Iniciar Tiquet.................................................................................74 5.3.3 Diagrama de seqüència Cobrar Article per Codi................................................................74 5.3.5 Diagrama de seqüència Informar Efectiu............................................................................75 5.3.6 Diagrama de seqüència Totalitzar Tiquet............................................................................77 5.3.7 Diagrama de col∙laboració Tancament de Caixa.................................................................77 5.3.8 Diagrama de col∙laboració Arqueig de Caixa.....................................................................78 5.3.9 Diagrama de seqüència Pagament de Caixa........................................................................79 5.3.10 Diagrama de seqüència Devolució d'Articles....................................................................81 5.3.12 Diagrama de seqüència Entrada d'Usuari..........................................................................81

5.4 Disseny de la interfície gràfica d'usuari (GUI)...........................................................................82 5.4.1 Pantalla Informar d'efectiu...................................................................................................83 5.4.2 Pantalla Pagament de caixa.................................................................................................84 5.4.3 Pantalla Devolució d'articles...............................................................................................85 5.4.4 Pantalla Cobrar articles........................................................................................................86



5.4.5 Pantalla Tancar transacció efectiu.......................................................................................87 5.4.6 Pantalla Tancar transacció TEF...........................................................................................88

6 Glossari de termes de negoci...............................................................................................................88 7 Bibliografia..........................................................................................................................................91 8 Annex...................................................................................................................................................92

8.1 Possibles ampliacions futures de TPV2.0...................................................................................92 8.1.1 Sistema de promocions.........................................................................................................93 8.1.2 Control de presència.............................................................................................................93

8.2 Quantificació del volum de tràfic................................................................................................93 8.3 Recomanacions d'infraestructura.................................................................................................94

8.3.1 Maquinari.............................................................................................................................94 8.3.2 Sistema operatiu i entorn.....................................................................................................95 8.3.3 Llenguatge d'implementació................................................................................................96

8.4 Llista del programari utilitzat......................................................................................................96

Índex d'il∙lustracionsDates clau del TFC..................................................................................................................................13Gannt de la realització del TFC...............................................................................................................14Configuració típica d'un sistema TEF.....................................................................................................29Diagrama de casos d'ús actor Encarregat................................................................................................31Diagrama de casos d'ús actors Caixer, Client, Empleat i TEF................................................................32Diagrama de casos d'ús actor Timer i Central.........................................................................................33Topologia de xarxa d'una configuració de dues botigues.......................................................................37Diagrama d'entitat/relació.......................................................................................................................65Diagrama estàtic de classes del model de negoci...................................................................................68Detall de les classes d'entitat...................................................................................................................69Diagrama de classes d'Excepcions..........................................................................................................70Diagrama de classes d'Interfície d'Usuari...............................................................................................71Diagrama de classes de Persistència.......................................................................................................72Diagrama de seqüència Alta d'Usuari.....................................................................................................73Diagrama de seqüència Cobrar Article per Codi....................................................................................75Diagrama de seqüència Informar Efectiu................................................................................................76Diagrama de seqüència Totalitzar Tiquet................................................................................................77Diagrama de col∙laboració Tancament de Caixa.....................................................................................78Diagrama de col∙laboració Arqueig de Caixa.........................................................................................79Diagrama de seqüència Pagament de Caixa............................................................................................80



Diagrama de seqüència Devolució d'Articles..........................................................................................81Diagrama de seqüència Entrada d'Usuari...............................................................................................82Pantalla Informar d'efectiu.......................................................................................................................83Pantalla Pagament de caixa.....................................................................................................................84Pantalla Devolució d'articles...................................................................................................................85Pantalla Cobrar articles...........................................................................................................................86Pantalla tancar transacció efectiu............................................................................................................87Pantalla Tancar transacció TEF...............................................................................................................88

3 IntroduccióL'objectiu d'aquest capítol és descriure amb la màxima exactitud possible l'abast i el nivell de profunditat que comprendrà aquest TFC.

Aquest treball aborda la creació d'un programari de gestió dels terminals punt de venda (en endavant TPV) anomenat TPV2.0 i per a la empresa client KOBRABO. Aquesta empresa i totes les seves característiques i condicions son simulades i s'utilitza a fi efecte de donar al treball la màxima similitud possible amb un entorn real.

L'eina TPV2.0 està destinada a explotar amb la màxima eficàcia possible la gestió del cobrament als clients a les botigues KOBRABO. El programari esmentat ha de comprendre tot el necessari per a poder gestionar les operacions de venda d'una botiga així com pels processos auxiliars que se'n deriven.

3.1 Situació actualLa empresa KOBRABO, de distribució i venda al detall d'aliments, és una de les empreses més dinàmiques i emergents del sector. Fundada al 1995 i amb un creixement anual en facturació del 19% i amb una expansió anual del 15%, s'està posicionant ràpidament al mercat i fentse un lloc al sector.

Disposa de 54 botigues , entre pròpies i franquícies, repartides pel territori català. També disposa d'unes oficines centrals a Figueres, Girona, seu de la companyia.

A finals de l'any passat la cadena KOBRABO va adquirir tots els actius de la fallida cadena EL PINGU, amb 12 botigues operatives, i recentment també ha comprat la cadena IRASKO amb 11 botigues operatives més. D'aquesta manera, actualment, la cadena KOBRABO compta amb una heterogeneïtat gens desitjable en quant als sistemes TPV, la qual cosa no afavoreix gens a l'automatització, optimització i seguretat dels processos de venda a botiga.



Actualment, el sistema de cobrament a les botigues es realitza mitjançant diferents models de caixes registradores de les marques Epson, IBM i Toshiba. Aquestes màquines registradores treballen amb PLU però tenen diferents operatives depenent de la marca i el model. La consolidació de les dades de facturació es resol mitjançant un programari instal∙lat en combinació amb el TPV i fet a mida per a cada model. Aquest unifica el format de sortida de les dades abans de processarles i enviarles a la central via mòdem per a la seva posterior consolidació i tractament.

Els problemes més importants, actualment, són la incapacitat d'implantar polítiques unificades d'operativa de cobrament a botiga, tancaments de caixa, resolució de problemes amb els quadraments de caixa, el control d'estocs, una actualització àgil de preus, formació a futurs usuaris, etc... ja que cada marca o model de màquina té unes particularitats determinades i diferenciades de la resta a la majoria de les operacions de venda.

Genèricament, les principals demandes del client envers el nou sistema son les següents:

En quant al procés de cobrament:

○ Estandarditzar la operativa de cobrament a totes les botigues de la cadena per tal de tenir la mateixa.

○ Recollir les noves necessitats dels diferents departaments de la companyia (màrqueting, comercial, administració, compres, etc...) envers la botiga, per reflectirho al programari.

○ Agilitzar el pas per caixa per reduir el temps d'espera a les cues i per augmentar el nº de clients per unitat de temps.

○ Ferho mes segur i tolerant a errors humans o tècnics.

○ Automatitzar i ajudar al procés de venda.

En quant al procés d'obertura i tancament de caixa diaris:

○ Facilitar el procés d'obertura i ferho mes segur. També facilitar el procés de tancament comptable de caixa.

En quant als controls d'efectiu i producte a la botiga:

○ Al fer el tancament diari augmentar la seguretat i el control dels diners.

○ Establir el màxim número de controls a les operacions de caixa.

○ Fer un seguiment el màxim d'acurat possible als moviments d'estoc i d'efectiu de la botiga.



En quant a la generació i consolidació de les dades que es generen diàriament:

○ Agilitzar el procés d'enviament a la central.

○ Eliminar el procés de conversió previ a l'enviament.

En quant a la plataforma de maquinari:

○ Prescindir de les màquines registradores i substituirles per terminals punt de venda, més barats, eficients i ràpids.

3.2 Àmbit i objectius del TFCEl projecte es centra a l'anàlisi i disseny d'un programari que gestioni totalment les necessitats de la botiga envers el procés de cobrament, que comprèn en termes generals l'obertura de caixa, el cobrament pròpiament dit i el tancament de caixa així com la consolidació de dades de vendes i consum a una BD centralitzada.

Aquest sistema ha de ser capaç de treballar en una xarxa local amb més d'un TPV i a més, amb una xarxa de llarg abast que comprengui de forma teòrica un número il∙limitat de botigues. L'abast del projecte finalitza un cop les dades de les vendes han sigut correctament integrades a la BD central al finalitzar el dia.

També queden inclosos tots els subsistemes que es puguin derivar d'aquests objectius principals, tal com un petit sistema de promocions, el control de medis de pagament (VISA, etc...) o la gestió dels perifèrics adients pel cobrament (teclat, visor, calaix portamonedes, balança, etc...).

Aquests objectius s'han d'aconseguir amb el mínim cost possible i amb la limitació de temps que comprèn des de l'inici de projecte el 30/09/08 fins a la fi del mateix el 9/1/08. En total 102 dies naturals disponibles.

3.3 ExclusionsQueden exclosos de l'abast d'aquest projecte els següents subsistemes, per les següents raons:

● Aprovisionament. Donat que és una cadena composada d'una sèrie de botigues i gestionada per una seu central, les compres de producte no les fan les botigues i ni tan sols han de gestionar comandes. Aquestes en fan en funció del consum de la botiga i amb processos automàtics des de la central.



● Promocions. Donada la gran varietat i complexitat de les promocions al punt de venda, en aquest primer projecte únicament es tenen en compte promocions senzilles formades per descomptes o tipus 3 per 2 (per la compra de tres productes, el client només en paga dos). La resta queden exclosos.

● Consultes a la base de dades central respecte als històrics de vendes o a dades estadístiques, ja que aquesta part pertany a un mòdul específic de mineria de dades.

3.4 Anàlisi de riscosL'anàlisi de riscos durant la confecció del projecte, a les fases d'anàlisi i disseny, no es tindrà en compte donat que totes les restriccions materials, econòmiques, humanes, etc... excepte la del temps, s'aborden des d'un punt de vista teòric i són portades a terme per una sola persona. D'aquesta manera, qualsevol imprevist envers el factor temps ha de ser solucionat mitjançant la reestructuració de les tasques i la modificació del diagrama Gantt.

3.5 MetodologiaEl paradigma que s'usarà pel projecte serà l'orientació a objectes.

La modelització es farà amb UML 2.0 i textual, depenent dels casos i la confecció dels diagrames UML es portarà a terme amb l'eina MagicDraw.

Dintre del anàlisi i disseny orientat a objectes, el procés escollit per a desenvoluparlo és el Procés Unificat (UP). Per les limitacions de temps i recursos disponibles solament s'abordarà en profunditat la primera de les tres principals iteracions que el composen. Aquesta iteració recull la recollida de requisits, l'anàlisi i el disseny i nivell de profunditat i abast d'aquesta iteració és suficient per a donar una idea clara, precisa i realitzable dels objectius de l'eina que es volen exposar en aquest treball.

La interfície gràfica pels prototipus es portarà a terme utilitzant la llibreria Swing del SDK 1.6.0 de Java i l'entorn de desenvolupament Eclipse.

El tipus d'arquitectura del programari serà bàsicament centralitzat, excepte alguns mòduls de gestió de dades que poden ser distribuïts i amb una estructura clientservidor. Els motius principals per prendre aquesta decisió són els següents:

● El sistema de cobrament està clarament definit en un punt físic (maquinari TPV) i amb una orientació clara a un sol usuari (caixer).

● La càrrega del sistema està clarament definida i condicionada per la cadència dels



clients i tant el número d'usuaris que accedeixen al sistema, com el volum de dades emmagatzemades de forma persistent, com el nº de transaccions executades en paral∙lel, estan previstes i acotades perfectament.

● Tots els requeriments funcionals es poden resoldre executant codi ubicat localment.

● El sistema ha de tenir una alta disponibilitat per a treballar de forma autònoma així com una alta adaptabilitat a entorns hostils com xarxes d'àrea local deficients, xarxes de telecomunicacions amb talls, caigudes del sistema central, etc...

● La previsió de creixement futur serà sempre el num de terminals a instal∙lar o bé centrat en el sistema central (fora de l'abast del projecte) i serà pràcticament nul en nous requeriments quantitatius de procés o capacitats del TPV. Donat que es dissenyarà sota el paradigma OO, serà prou obert com per a permetre noves ampliacions funcionals amb un mínim cost i sense haver de canviar d'arquitectura en aquest sentit.

3.6 Tasques a executarEn aquest apartat s'aborda la planificació global del projecte utilitzant diagrames de Gannt generats amb una eina de planificació.



3.6.1 Diagrama Gantt del pla de treball, planificació i dates clau

Les dates clau venen clarament marcades pels lliuraments de les PAC2, PAC3 i document final TFC. Cada fase disposa pel seu compliment de 38, 38 i 25 dies respectivament. Les subtasques de cada tasca o fase principals venen quantificades en dies de treball.


Il∙lustració : Dates clau del TFC


També, donat que només es disposa d'un sol recurs humà, aquesta primera planificació s'ha simplificat posant les tasques en seqüència, tot i que si es disposés de més recursos humans, hi ha certes tasques que es podrien fer en paral∙lel.

4 Fase d'anàlisi i requisitsEn aquesta fase del treball es documenten els requisits del futur sistema amb un cert nivell de detall, suficient perquè es pugui començar a perfilar el funcionament del sistema, format per diferents subsistemes. Aquests requisits es recullen en funció de les necessitats del client, del mercat i de l'entorn actual.

Per a detallar què fa el sistema actualment i què ha de fer en un futur, s'utilitzen elements descriptius textuals com el model de negoci, els guions o els casos d'ús.

4.1 El model de negociLa empresa KOBRABO, de distribució i venda al detall d'aliments, és una de les empreses


Il∙lustració : Gannt de la realització del TFC


més dinàmiques i emergents del sector. Fundada a la ciutat de Girona el 1995 i amb un creixement en facturació del 19% i en expansió del 15% anuals, s'està posicionant al mercat i fentse un lloc al sector ràpidament.KOBRABO disposa de 54 establiments , entre botigues pròpies i franquícies, repartides pel territori català. El ritme d'expansió ha sigut del 15% durant els darrers 3 anys. Així, l'any passat es van obrir 8 botigues, l'anterior 7 i l'anterior 6 més, sense comptar amb les darreres adquisicions d'altres cadenes. La seva expansió és del tipus “taca d'oli”, obrintse circularment entorn a la central situada a Girona i integrant noves cadenes de botigues que troba al seu pas.

Les botigues són rentables en zones d'uns 10.000 habitants o més, la qual cosa permet una expansió còmoda ja que les mateixes es poden encaixar tant en poblacions petites com en barris de grans ciutats.

Actualment hi ha a Catalunya unes 120 poblacions de més de 10.000 habitants i Kobrabo està present a les més importants com Barcelona, amb 19 botigues, Girona amb 14 botigues (punt inicial de la expansió), Lleida amb 6 botigues i Tarragona amb 6 botigues més. La resta de botigues estan repartides en poblacions menys importants a raó d'una botiga per població. Les oficines centrals i seu de la companyia estan a Figueres, Girona.

A finals de l'any passat la cadena KOBRABO va adquirir tots els actius de la fallida cadena EL PINGU, amb 12 botigues, i recentment també ha comprat la cadena IRASKO amb 11 botigues més. D'aquesta manera, actualment, la cadena KOBRABO compta amb una heterogeneïtat gens desitjada, en quant als sistemes de cobrament a la botiga, la qual no afavoreix gens a l'automatització, optimització i seguretat dels processos de venda.

El format i grandària de les botigues varia segons el lloc d'implantació per adaptarse millor a l'entorn. Actualment existeixen tres formats genèrics de botiga:

● Botiga de barri format compacte: Superfície de venda entre 100 i 150 m2 amb 2 o 3 caixes. Una d'elles ha de fer les vegades de caixa central, donada la manca d'espai. És un tipus de botiga adaptada a nuclis de població on el preu del m2 és elevat per la seva cèntrica ubicació, però que compensa econòmicament per l'alta circulació de clients o bé pel seu nivell adquisitiu.

● Botiga de barri format ampli: Superfície de venda entre 150 i 400 m2. De tres a vuit caixes i caixa central separada. És un tipus de botiga adaptada a zones d'extraradi on els preus dels locals són més continguts. Es necessiten més m2 de venda per compensar els costos i la menor afluència de clients per unitat de temps.



● Botiga de centre comercial tipus supermercat: Superfície de venda entre 400 i 2500 m2. De sis a quinze caixes amb caixa central separada i mostrador d'atenció al client. És un establiment de grans dimensions que funciona sempre inserit a un centre comercial o gran superfície, amb els seus horaris i amb un gran volum de facturació.

Actualment, el sistema de cobrament a les botigues es porta a terme mitjançant caixes registradores de les marques Epson, IBM i Toshiba, de diferents models. Aquestes màquines registradores treballen amb codis PLU i tenen diferents operatives, depenent de la marca i model. La consolidació i enviament de les dades de facturació es resol mitjançant un programari instal∙lat en combinació amb el TPV, i fet a mida per a cada model, que actua com a interfície i unifica els formats de sortida de les dades abans de processarles i enviarles a la central. Amb aquest sistema s'aconsegueix que diferents formats de dades d'origen es puguin integrar en una sola base de dades centralitzada.

Avui dia els problemes més importants estan relacionats amb la incapacitat d'implantar polítiques unificades a botiga, com el cobrament, els tancaments de caixa, la resolució de problemes amb els quadraments de caixa, el control d'estocs, una actualització àgil de preus, formació a futurs usuaris, facilitat d'ús dels terminals, etc...

4.2 Guió general d'un punt de venda actualA l'inici de dia, en Marc, l'encarregat de la botiga, abans d'obrir aquesta al públic, té una sèrie de tasques a fer.

Primerament desactiva les alarmes, arrenca o supervisa la resta de sistemes de la botiga, com la il∙luminació, el sistema de climatització, el fil musical, etc... i inicia les caixes enregistradores. A continuació fa una consulta al correu electrònic o al fax (depenent del nivell tecnològic de la botiga) per esbrinar si hi ha hagut canvis de preus. Observa que, efectivament, han arribat els següents canvis per al dia d'avui:

● El Nescafé de 500 grs. s'ha apujat fins els 4.50 €/u.

● Les llaunes d'escopinyes de la marca Calvo, de tots els formats, s'han apujat un 5%.

● Els iogurts variats de fruites de la marca Danone, pac de vuit unitats, s'ha apujat a 1.35 €/u.

● Ha baixat el preu del vi de Toro de Ronda fins als 2.35 €/u.

● S'han donat de baixa les fruites d'estiu: melons, préssecs, prunes, síndries i



nectarines.

● S'incorporen a la família de precuinats els articles 'base de pizza casolana', 'canelons El Pavo' i dos nous tipus de salses de la marca blanca Kobrabo.

Seguidament, dóna instruccions per què els reposadors preparin els lineals de producte amb els nous canvis, ja sigui posant etiquetes, retirant articles del lineal, posant articles nous, etc... Un cop fets els canvis físics, introdueix els canvis manualment a la caixa principal perquè es transmetin a la resta de caixes enregistradores. Finalment comprova que els preus s'hagin aplicat a la resta de caixes.

Aquell dia ha arribat l'Albert, un nou caixer provinent de la botiga d'Igualada i que per motius personals ha demanat el trasllat a aquesta botiga. Te experiència amb el sistema però donat que el tipus de caixa en aquesta botiga és lleugerament diferent, se li han de donar instruccions de com funcionen i com pot accedir a les funciona habituals per fer el cobrament. Finalment, només cal donarli una clau (física) per que pugui fer cobraments a caixa.

A l'hora de l'obertura de la botiga, aixeca la persiana per començar la venda i tot seguit s'inicia el cobrament amb els primers clients que compren.

Cada caixer té una clau física que permet cobrar amb el nivell de permisos que aquesta clau li atorga.

Just abans de marxar a dinar en Marc demana a l'Albert que li faci un llistat amb el total de les vendes fetes fins al moment. Junts compten els diners de caixa i verifiquen que fins al migdia l'arqueig dóna una diferencia de zero. Al tornar de dinar i abans del canvi de torn de l'Albert, repeteixen l'operació amb resultats menys òptims, ja que en Marc enregistra a la seva llibreta una diferència de 1.20 euros a favor de la caixa i l'Albert marxa fins al dia següent.

A la tarda, es repeteix el mateix procés de cobrament i controls regulars a la resta de caixers.

Al final de la jornada, un cop tancada la botiga, en Marc es disposa a fer els tancaments de caixa comptant amb els arquejos anteriors i acumulant les diferències de caixa. Un per un, demana als caixers i caixeres que llistin les vendes i recomptin la caixa. Finalment, un cop aclarits tots els motius de les diferències de caixa, els caixers marxen a casa fins al dia següent.

En Marc es queda per finalitzar la jornada als TPV i enviar les vendes a la central via



mòdem, juntament amb un informe per fax o correu electrònic de les incidències del dia a nivell comptable.

4.3 Guions importants del futur sistemaEls guions són una via prèvia a la creació dels casos d'ús que permet vehicular i sistematitzar la informació que l'usuari explica en forma de petites històries o necessitats futures.

4.3.1 Obertura de caixaA l'inici del dia, abans d'obrir la botiga, l'encarregat fa l'obertura de caixa, que consta dels següents passos, a tots els TPV, amb els següents passos a cadascun d'ells:

● Introduir canvi suficient al calaix portamonedes, normalment uns 150 euros, i informar al sistema.

● Actualitzar els preus a la caixa.● Iniciar jornada al TPV.

4.3.2 Tancament de caixaAl final del dia, després de tancar la botiga, l'encarregat fa el tancament de caixa a tots els TPV, amb els següents passos a cadascun d'ells:

● Arqueig de caixa (això ho fa el caixer).● L'encarregat demana al sistema un llistat de moviments d'efectiu, per esbrinar si les

dades del sistema i les informades pel caixer coincideixen. En cas negatiu, el caixer ha de repetir l'arqueig de caixa, ja que possiblement hi ha un error de comptatge d'efectiu. En cas contrari ha de justificar degudament la diferència.

● L'encarregat procedeix a informar al TPV que el dia ha finalitzat.● Un cop el dia ha finalitzat, el TPV automàticament envia els registres de vendes a la

BBDD central i finalitza el procés.

4.3.3 Guió de cobrament d'articlesUn client arriba al TPV amb productes per pagar. El caixer s'identifica al TPV i selecciona el mòdul de cobrament de tiquets. Introdueix el codi numèric del primer producte, o bé passa el producte per l'escànner. Repeteix el passos anteriors fins que no queden productes pendents de cobrar. Llavors se li pregunta al client si posseeix la targeta de client i s'informa al client de la quantitat a pagar. Aquest paga pel medi que desitgi (efectiu, tarja de crèdit o



val de descompte). Finalment, si el pagament és correcte, es tanca la transacció i es lliura al client un tiquet en paper.

4.3.4 Guió de pagament amb tarja de crèditEl caixer finalitza el cobrament d'articles i totalitza el tiquet. El sistema informa al client de l'import a pagar corresponent al total del tiquet. El client demana pagar amb tarja. El caixer identifica de forma visual la correcció del DNI. El caixer introdueix la tarja de crèdit a la ranura i el sistema de TEF prova de gestionar el cobrament. Si aquest és correcte, es tanca el compte automàticament i s'imprimeix el tiquet en paper. Finalment, el sistema es prepara per a un nou cobrament. En cas contrari, l'aplicació torna a l'inici del guió.

4.3.5 Guió de pagament amb efectiuEl caixer finalitza el cobrament d'articles i totalitza el tiquet. El sistema informa al client de l'import a pagar corresponent al total del tiquet i llavors el client demana pagar en efectiu. El client fa el pagament amb l'import just o amb més import del que es necessita. Si l'import subministrat pel client és inferior, el caixer ha de rebutjar el pagament i tornar a demanar l'import. Altrament, el caixer informa al sistema de l'import subministrat al client. El sistema obre el calaix portamonedes i informa al caixer del canvi a tornar pel client, que pot ser zero o superior. El caixer torna al client l'import informat pel sistema, agafant diners en efectiu del calaix portamonedes. El caixer tanca el calaix portamonedes i informa al sistema de que la transacció ha sigut efectuada amb èxit. El sistema imprimeix un tiquet en paper per al client. Finalment el sistema es prepara per un nou cobrament.

4.4 Algunes característiques del model de negociEl model de negoci de la distribució en general, també conegut com a retail, i més concretament el model de negoci de Kobrabo, posseeix unes característiques específiques envers algunes normes, operacions i maneres de fer que és important conèixer.

4.4.1 Actualització de preus a la botigaQuan hi ha un canvi de preus a la botiga, aquest ve determinat per la central. La botiga no té cap control sobre els seus preus de venda i és la central la que ho gestiona de manera exclusiva. Aquest sistema és un dels pilars de les cadenes de distribució i és també un dels punts diferencials amb el petit comerç: una gestió de preus centralitzada.Quan a la Central es decideix canviar el preu de venda d'un article, donarho de baixa,



afegir nous articles o variar les seves característiques, llavors es prepara un nou catàleg complert i es posa a disposició de la botiga. Normalment això es fa en un procés nocturn, mentre la botiga no fa venda. Quan el sistema intermedi o caixa central ho rep, fa una comparació amb el catàleg vigent a la botiga. En cas que existeixi alguna diferència (alta, baixa o modificació) es passa un avís per pantalla perquè el responsable de la botiga ho supervisi i posteriorment posi els preus a disposició dels TPV.

4.4.2 Els impostos i els descomptesA la venda al detall en botigues on s'emeten factures en format tiquet o justificant de compra, tots els imports ja tenen els impostos inclosos (el cas d'Espanya és l'iva) i no es desclosa explícitament preu per preu. En tot cas, solament es necessària una referència o informació al client de l'estil “iva inclòs” perquè aquest en sigui conscient de que paga l'impost corresponent. Llavors és el departament d'administració de Kobrabo el que dedueix el tipus d'iva de cada producte (hi ha del 4%, del 7% i del 16%) per fer la declaració fiscal corresponent.

Tanmateix, a l'aplicar un descompte, s'ha de tenir en compte que aquest ha d'afectar al preu base i no a la part d'impostos, ja que Kobrabo no pot fer un descompte sobre un impost “que no és seu”.

A la pràctica, el mètode seria agafar el preu de l'article, eliminar els impostos, aplicar el descompte sobre la base i tornar a aplicar l'impost sobre aquest resultat.

Exemple

● Preu de l'article iva inclòs: 3.45 €.

● Iva aplicat: 7%.

● Descompte Kobrabo: 15%.

● Pas 1, treure iva: 3.45 (3.45 * 0.07) = 3.2085;

● pas 2, aplicar descompte: 3.2085 – ( 3.2085 * 0.15) = 2.547225;

● pas 3, aplicar l'iva al resultat i arrodonir: 2.547225 + ( 2.547225 * 0.07) = 2.7255... = 2.73 €.

4.4.3 Senyalització de preusSegons la llei vigent, el preu d'un producte a un establiment ve determinat per l'etiqueta de l'expositor i no pel preu introduït al TPV. Per tant, una actualització de preus al TPV ha



d'anar sempre precedida d'una actualització de preus als expositors. Altrament, si existeix un conflicte entre TPV i expositor, i aquest és en contra del client, aquest té dret a pagar el preu marcat a l'expositor i no al TPV. En base a això, els canvis de preus mai haurien de ser automatitzats i directes al TPV i sempre haurien d'anar associats a una autorització prèvia a botiga i a una actualització de l'etiquetat.

4.4.4 Eliminació d'informacióA efectes legals un tiquet emès a un client té la mateixa validesa que una factura. Per tant, un tiquet o el seu contingut mai es pot eliminar de forma física. En cas de voler anul∙lar un tiquet o de voler retrocedir una compra, l'única manera de ferho és enregistrant al sistema un tiquet o una línia del mateix import en negatiu per anul∙lar l'anterior.

4.4.5 Cicle de vida de la botigaEl cicle mes llarg que esdevé a la botiga , en quant a operacions, té una durada d'un dia. Tots els processos cíclics són més curts i succeeixen dintre d'aquest termini. Cada jornada natural (dia i nit) és un cicle de l'aplicació exceptuant alguns processos puntuals com l'aprovisionament de material (no inclòs en aquest treball) o bé algunes operacions on es veu involucrada alguna devolució de producte per part del client provinent de compres de dies anteriors.

4.4.6 Pèrdua desconegudaEl terme pèrdua desconeguda fa referència a la desaparició de gènere o be de diners en efectiu a la botiga, sense que els sistemes de control puguin enregistrarho o comptabilitzarho.

Aquesta pèrdua desconeguda és la suma del furt extern, comès per clients, el furt intern, comès pel propi personal de Kobrabo, els errors dels proveïdors i els errors de control o gestió.

El TPV és un punt “calent” per al furt intern de diners en efectiu. És molt important saber detectar on son els punts febles del sistema des del punt de vista del caixer malintencionat per evitar el màxim número possible de fuites d'efectiu. Un factor important que ha de tenir en compte el sistema és el fet d'auditar qualsevol moviment de caixa, ja sigui correcte o incorrecte.

Un exemple de “forat” de seguretat seria permetre la eliminació de línies de tiquet sense que quedi constància d'aquest fet. Un guió d'exemple podria ser el següent:



1. El caixer finalitza el cobrament de tots els articles del client.

2. El caixer NO totalitza el tiquet però informa al client de l'import que ha de pagar mitjançant la pantalla del total acumulat.

3. El client abona l'import de la compra.

4. El caixer pregunta al client si vol el tiquet.

5. El client denega l'oferiment i marxa amb la compra.

6. Un cop el client ha marxat, el caixer elimina la darrera o mes línies del tiquet de forma manual i finalitza el tiquet.

7. Extreu de la caixa l'import en efectiu corresponent a les línies eliminades.

Amb aquesta seqüència d'operacions, el tancament diari no detecta cap diferència al fer el tancament. Tot i que la desaparició dels diners en efectiu no va acompanyada de la desaparició física del producte, el desfasi no es detecta fins al següent inventari. A més, la relació directa entre la manca de producte i la manca d'import no es pot establir ja que la pèrdua desconeguda pot estar relacionada amb qualsevol dels altres motius anteriorment esmentats.

Per aquesta raó, els controls han de ser molt acurats o be s'han d'impedir al màxim aquest tipus de manipulacions de la operativa.

4.4.7 Tancament a ZeroEl terme “Tancament a Zero” es refereix al fet que quan un TPV no ha fet cap venda, es a dir, no ha generat cap tiquet en aquella jornada, s'ha de generar igualment un tancament per informar al sistema d'aquest fet.

Extrapolat al cas real d'una botiga, també es pot donar el cas que s'obri la botiga i que cap client entri durant tot al dia fins a l'hora de tancar. Tot i que la possibilitat és quasi nul∙la, en cas de succeir s'ha de preparar el sistema perquè sigui capaç d'enregistrar l'absència de tiquets (tancaments de tots els TPV a zero) per evidenciar aquest fet.

4.4.8 Nivells de prioritat del sistemaLes característiques d'un sistema de gestió de punt de venda fan que certes prioritats de disseny o d'arquitectura variïn amb respecte a un sistema convencional, com pot ser una estació de treball o un punt d'accés web, etc... En cas de conflicte a l'hora de prendre una



decisió de disseny, l'ordre de prioritats ha de ser:

1. Disponibilitat,

2. seguretat,

3. facilitat d'ús,

4. resta de característiques.

Nivell de disponibilitat: Un sistema de gestió de vendes a botiga no és un sistema en temps real, però les característiques del procés de venda fan que la disponibilitat del TPV sigui un punt clau. Tant el maquinari com el programari han d'estar dissenyats per poder operar en qualsevol circumstància amb uns temps de latència molt concrets. A tots ens ha passat alguna vegada estar a la cua d'una caixa per pagar i veure com de sobte deixa d'estar operativa o té problemes. Aquest fet aparentment tan senzill pot provocar que, si no tenim cap més opció per pagar o bé si tenim pressa, deixem el producte abandonat i sortim per la zona de “sortida sense compra”.La manca d'operativitat d'un TPV es pot traduir en pèrdues econòmiques directes i aquesta pot esdevenir per més d'un motiu: fallada tècnica, manca de coneixement del caixer, problema de coherència amb els preus, problemes de permisos d'accés, problemes amb el medi de pagament del client, etc...Nivell de seguretat: Donat que un TPV treballa bàsicament amb diners (efectiu o electrònic) el seu nivell de seguretat és també un factor important. Poden haverhi fuites d'efectiu per molts motius: errors fortuïts o intencionats dels operadors de caixa, errors amb el maquinari o programari que donen resultats imprecisos, etc... Qualsevol d'aquests errors es pot traduir directament en problemes amb un client o en problemes amb l'efectiu de caixa.Facilitat d'ús: El tercer punt important, tot i que subordinat als anteriors, és la capacitat del sistema per adaptarse al usuari. Aquí juga un paper molt important la IHO (interacció humana amb els ordinadors) i per tant el disseny d'aquesta ha de ser molt acurada i fruit d'un estudi minuciós del comportament de l'operador de caixa.

4.4.9 Codi d'article intern envers codi EANTota referència d'article que estigui a la venda o dintre del flux de negoci de Kobrabo ha de tenir un codi intern. Aquest codi marca la diferenciació que fa Kobrabo d'aquesta referència respecte a la resta de referències del seu catàleg. Aquest codi intern és una cadena alfanumèrica única de 5 dígits que relaciona el producte amb totes les seves dades



rellevants com preu, característiques, família o subfamília, etc...

Per una altra banda, el codi EAN és un codi europeu d'identificació d'articles de 13 xifres (hi ha variacions de longitud depenent del format) que identifica el producte dintre d'un sistema global, aliè a Kobrabo. Donat que aquest sistema té la particularitat de poder ser “llegit” per medis òptics, és aprofitat pels processos automatitzats com són la venda, la traçabilitat, etc... però s'ha d'enllaçar amb el codi intern de l'article per qualsevol gestió interna posterior.

Aquesta diferenciació es pot veure clara amb dos exemples:

Kobrabo té a la venda un pac sis de pomes envasades “primera qualitat”, a la secció de fruiteria, amb el codi intern 17011. Aquest producte es compra a cinc proveïdors diferents, cadascun dels quals té el seu propi codi EAN. A nivell de venda, Kobrabo no fa cap distinció envers l'origen del producte, ja que aquest es ven sota marca pròpia. Per tant, a l'hora de la venda, qualsevol dels cinc codis EAN “apunta” al codi 17011 quan passa per caixa.

4.5 Requeriments no funcionals per al nou sistemaEn un primer contacte amb la comissió interna de Kobrabo responsable del projecte , on s'inclouen membres dels principals departaments, s'han extret de forma genèrica les principals necessitats envers el sistema:

● En quant al procés de cobrament:

○ Estandarditzar l'operativa de cobrament a totes les botigues de la cadena per tal de tenir la mateixa operativa i facilitar els processos de formació de nous operadors/es (caixers/es o responsables de botiga).

○ Recollir les noves necessitats dels diferents departaments de la companyia (màrqueting, comercial, administració, compres, etc...) envers la botiga, per reflectirho al programari.

○ Agilitzar el pas per caixa per reduir el temps d'espera a les cues i per augmentar el numero de clients per unitat de temps.

○ Ferho més segur i tolerant a errors humans i tècnics.

○ Automatitzar i ajudar al procés de venda.

○ Permetre un procés de formació i adaptació ràpid als nous caixers.

● En quant al procés d'obertura i tancament de caixa diaris:

○ Facilitar el procés d'obertura i fer més segurs els processos d'obertura i



tancament comptable de caixa.

● En quant als controls d'efectiu i producte a la botiga:

○ Augmentar la seguretat i el control dels diners al fer el tancament diari.

○ Establir el màxim número de controls a les operacions de caixa.

○ Fer un seguiment el màxim d'acurat possible als moviments d'estoc i d'efectiu de la botiga.

● En quant a la generació i consolidació de les dades que es generen diàriament:

○ Agilitzar el procés d'enviament de dades a la central.

○ Eliminar el procés de conversió de dades previ a la integració de vendes a la base de dades centralitzada.

● En quant a la plataforma de maquinari:

○ Prescindir de les màquines enregistradores i substituirles per terminals punt de venda, mes barats i eficients.

Genèricament, les funcions principals del TPV han de ser:● Cobrament:

○ Cobrament de línies:■ Entrada per scanner.■ Entrada manual del codi.■ Entrada manual de la quantitat.■ Retrocedir línies errònies.

○ Totalitzar tiquet:■ Selecció del pagament.■ Introducció del pagament.■ Tancar tiquet.

● Obertura de dia:○ Actualització inicial de dades.

■ Articles i preus.■ Promocions.■ Paràmetres variables.

○ Introducció del canvi del calaix portamonedes.● Tancament de dia:

○ Arqueig de caixa.



○ Tancament comptable.● Consulta d'articles.● Manteniment de paràmetres locals.● Consulta de tiquets.● Consolidació de dades.● Comunicacions:

○ Enviament de dades a central.○ Recepció de dades.

4.5.1 El control del calaix portamonedesAl sistema actual de Kobrabo la gestió i control de les obertures de calaix no permeses és ineficaç o inexistent, en el sentit de que no es té un control acurat envers quan s'obre el calaix i en quines operacions es fa. Això, actualment, succeïx a Kobrabo per l'antiguitat del sistema i per l'heterogeneïtat de les plataformes de maquinari i programari al punt de venda. Per tant, quan un caixer vol fer una utilització incorrecte de l'efectiu de caixa, aquesta és més vulnerable per la manca de control.

Al nou sistema, el calaix portamonedes només es pot obrir de forma controlada quan l'operació que s'està efectuant ho permeti; posteriorment s'ha de verificar que el calaix romangui tancat per continuar els processos de venda.

Les úniques situacions on es permet una obertura de calaix són:

● Al finalitzar un tiquet i si la forma de pagament escollida és efectiu.

● Al fer un pagament de caixa.

● En cas d'utilització de la tecla del pànic.

El calaix ha de romandre tancat a la resta de funcions perquè el sistema permeti que l'operativa continuï.

4.5.2 La tecla del pànicLa tecla del pànic té a veure amb els atracaments.

A una botiga de cara al públic és molt freqüent, malauradament, que succeeixi un atracament. En aquest cas l'objectiu acostuma a ser el calaix portamonedes. Donat que, per sobre de tot, s'ha de garantir la seguretat del caixer, en cas de que aquest es vegi involucrat i pateixi algun tipus d'amenaça, s'ha d'habilitar una funció d'emergència per obrir el calaix



portamonedes en qualsevol moment i permetre que el caixer entregui tots els diners de forma ràpida a l'atracador. Aquesta funció ha poder ser activada amb una tecla física, de fàcil accés i amb un etiquetatge no explícit es proposa “PNC” com a etiqueta tant al teclat físic com a la pantalla i a prova de manipulacions incorrectes; p. ex. obligar a fer tres pulsacions seguides. Al mateix temps, s'ha d'enregistrar aquesta obertura per poder justificarla degudament, a posteriori, un cop es revisin els esdeveniments del dia.

És un error pensar que afegint seguretat física al calaix com un pany, un fort blindatge, obertura amb retard, etc..., es pot dissuadir o evitar un atracament. En el millor dels cassos l'atracador s'emportarà el calaix o el TPV sencer, violentantlo, deixant un rastre de destrucció al seu voltant i ocasionant una despesa econòmica molt superior al import robat.

4.5.3 Les promocionsEn aquest projecte s'ha de modelar un prototip de sistema de promocions funcional però simplificat, donat que un sistema comercial complex que queda fora de l'abast d'aquest estudi per manca de temps. A l'annex d'aquest treball es fa constar com a millora futura la introducció a un projecte complex de gestió de promocions.

Exemple del prototip actual

A la Central es generen promocions que afecten a descomptes d'articles a nivell individual i a promocions “m x n”:

1. Promoció “Xocolata 3 x 2 : per la compra de qualsevol tipus de xocolata, emportise'n tres pel preu de dos. No acumulable”.

2. Promoció “10% de descompte en tots els articles de la llar. No acumulable”.

L'entitat Article té informació suficient per gestionar aquests tipus de promocions, ja que una promoció 3x2 no és més que un descompte del 100% sobre un dels articles, si al tiquet existeixen tres articles iguals.

Al fer el total del tiquet, el sistema calcula els descomptes i bonificacions, no acumulables entre sí, i emet els descomptes adients. En cas d'una devolució sobre articles promocionats, el sistema únicament te en compte els imports a retornar tot fent una consulta a l'històric.

Exemple de sistema complex

A la Central, diferents departaments sense relació entre ells (màrqueting, producte, comercial, atenció al client, etc...) generen les següents promocions, acumulables entre sí:



3. Promoció “Bon dia pel matí : per cada compra efectuada abans de les 12:00 li fem un 5% de descompte. No acumulable”.

4. Promoció “Avui li toca al Barcelonès: a totes les botigues del Barcelonès, cada compra és bonificada amb un 2% de descompte. No acumulable”.

5. Promoció “Xocolata 3 x 2 : per la compra de qualsevol tipus de xocolata, emportise'n tres pel preu de dos. No acumulable”.

6. Promoció “10% de descompte en tots els articles de precuinats. No acumulable”.

7. Promoció als clients habituals: “Si té tarja de client Kobrabo, li regalem la meitat dels articles de la seva compra (els mes cars) en cas de que li toqui el sorteig automàtic. Un cada dia a cada botiga”.

Es pot donar el cas que un client compleixi alternativament totes aquestes condicions i què el sistema hagi de calcular quines promocions li “activa” i quines no, donat que algunes no són acumulables entre elles i, en cas de que siguin acumulables, quines li atorguen mes benefici per evitar reclamacions posteriors. Aquest client, a més, pot retornar articles per qualsevol problema i el sistema ha de tenir en compte a l'hora de retrocedir la compra quines promocions estaven actives i a què afectaven.

A banda de la complexitat a la fase d'implementació, fase que queda fora de l'abast d'aquest treball, el fet de modelar totes aquestes característiques fa que s'hagin de tenir en compte una sèrie d'entitats, atributs i relacions altament complexes.

4.5.4 L'agent TEFL'agent de Transferència Electrònica de Fons (endavant TEF) és un programari extern que s'ha d'integrar al TPV per gestionar transaccions de diners electrònics o bancaris entre la entitat emissora i la receptora; al nostre cas entre la botiga i el client. Es pot afirmar que és la evolució tecnològica dels terminals bancaris, anomenats comunament “datàfons”. La principal diferència rau en el fet de que el datàfon és un sistema de maquinari electrònic, totalment extern al TPV i on les interaccions entre els dos sistemes han de ser traslladades manualment pel caixer. Normalment aquest enginy és propietat de la entitat bancària que el subministra.

Contràriament, el TEF és un sistema de programari que també s'integra dintre del programari del TPV i que interacciona a nivell intern per efectuar les operacions de cobrament. Aquestes poden ser recollir l'import del tiquet, aprofitar la impressora de tiquets



per emetre el comprovant, enregistrar dades de l'operació legalment permeses, etc...

Com ja s'ha dit, aquest agent és independent del desenvolupament de l'aplicació i normalment és subministrat (o és propietat) d'empreses dedicades en exclusiva a aquest tipus de processos.

4.6 ActorsA continuació es fa una primera identificació dels actors que poden tenir alguna relació amb el sistema, ja sigui de forma directa o indirecta.

Es considera un actor com un conjunt de funcions exteriors al sistema, que són executades en moments diferents i que probablement inicien accions del sistema diferents. El fet d'agruparles sota un mateix nom ens ajudarà a comprendre com es comporta el sistema a analitzar sota una determinada actuació externa.


Il∙lustració : Configuració típica d'un sistema TEF


4.6.1 Actors principals● Caixer

○ Actor humà que representa les accions efectuades per un caixer o caixera com a usuari bàsic del sistema de cobrament.

● Encarregat.○ Actor humà que representa les accions efectuades per un usuari amb perfil

administrador o responsable de processos. Aquest actor és una especialització del caixer ja que pot iniciar els mateixos casos d'ús i alguns més d'específics.

● Empleat○ Actor humà genèric que representa un usuari del sistema. És una generalització

dels dos anteriors.

4.6.2 Actors de recolzament● TEF

○ Actor no humà que representa les accions externes del sistema de transferència electrònica de fons (TEF).

● Timer○ Actor no humà que inicia processos automàtics programats que actuen dintre del

propi sistema analitzat.● Client

○ Actor humà que representa les accions efectuades pel client que vol adquirir productes.

● Central○ Actor no humà que representa les accions efectuades per la central. Bàsicament,

l'únic paper d'aquest actor és l'enviament de dades a les botigues.

4.6.3 Diagrama de casos d'ús actor EncarregatL'actor Encarregat és una especialització de l'actor Caixer ja que pot efectuar totes les seves operacions en cas necessari (cobrament, etc...) i a més pot iniciar accions de control reservades únicament al seu perfil.



4.6.4 Diagrama de casos d'ús actors Caixer, Client, Empleat i TEFAquest diagrama agrupa els casos d'us dels actors Caixer, Client, Empleat i TEF. Els dos primers estan estretament relacionats ja que Caixer és una especialització d'Empleat.

Per ajudar a la comprensió del diagrama s'ha omès la inclusió del cas d'ús Iniciar Sessió a tota la resta, ja que és necessari aquest primer abans d'iniciar qualsevol dels altres.

Els dos actors Client i TEF tenen funcions més concretes i aïllades entre elles.


Il∙lustració : Diagrama de casos d'ús actor Encarregat


4.6.5 Diagrama de casos d'ús actor Timer i CentralEn aquest diagrama es representa un sol cas d'ús iniciat per dos actors contraposats. Per una banda, l'actor Timer inicia el cas d'ús “Enviar pendents” en sentit botigacentral. En contraposició, l'actor Central inicia el mateix cas d'us, però en sentit contrari centralbotiga.


Il∙lustració : Diagrama de casos d'ús actors Caixer, Client, Empleat i TEF


4.7 Classes de negoci: Atributs i relacions principalsEn un primer anàlisi s'identifiquen les classes de negoci principals i els atributs o es comenten alguns en detall.

● Article ○ codi○ descripcioPantalla○ descripcioPaper○ pvp○ descompte

● Botiga ○ id○ nom○ adreça○ tel


Il∙lustració : Diagrama de casos d'ús actor Timer i Central


○ fax○ capçaleraTiquet: enmagatzema les linies que composen l'inici del tiquet en paper○ peuTiquet: enmagatzema les linies que composen el peu de tiquet amb missatges

tipus “gràcies per la seva compra”, etc...○ numTpvs: indica el numero de TPV's que han d'haver a la botiga

● Caixer ○ id○ password○ horari○ perfil

● CalaixPortamonedes ○ isObert

● Catàleg ● CentralDePreus ● ClientIdentificat

○ id○ tipus○ puntsAcumulats

● ControlEfectiu ○ hora○ caixer○ import

● EAN ● Empleat

○ dataAlta○ isActiu○ horari

● Encarregat ● Impressora

○ numColumnes● LiniaDeTiquet

○ codi○ quantitat○ descompte ○ total



● Persona ○ nom○ cognom1○ cognom2○ adreça

● Jornada ○ dataInici○ dataFi○ horaInici○ horaFi○ responsable○ diferenciaTotal: resultat de l'arqueig definitiu

● TeclatProgramable ○ teclaFuncio: estructura de dades que assigna a cada tecla una funció

determinada del programari● TPV

○ id○ idCentral: indica si el TPV fa les funcions de caixa central

● Visor ○ id: s'ha d'identificar ja que pot haverhi més d'un per caixa○ caractersPerLinia○ numLinies

4.7.1 Persistència de les dadesPer raons de disponibilitat del sistema, les dades han de tenir una alta persistència local. El motiu principal és la necessitat de garantir que davant de qualsevol problema de tipus endogen o bé exogen mai es poden perdre dades. Al mateix temps, tampoc es pot minvar l'operativitat de cobrament. Per exemple, un tall de corrent al mig d'un tiquet, una interrupció no controlada del programari, una caiguda de la xarxa local, etc...Tot i que el nucli del sistema (subsistema de cobrament) està pensat per executarse localment, donada la necessitat de tolerància a errades de la infraestructura de xarxa, alguns subsistemes no crítics poden funcionar sota arquitectura clientservidor.

Un cop dissenyada la base de dades s'ha de tenir en compte la replicació controlada de certes dades, tenint en compte el sistema de persistència en 3 nivells:



● Nivell local● Nivell intermediari● Nivell remot

4.7.1.1 Nivell local

Aquest primer nivell de dades ha d'estar situat físicament al mateix TPV. La majoria de les dades del sistema estan ubicades en aquest nivell. Aquestes dades són totes aquelles necessàries pel cobrament i processos repetitius crítics, com les dades del tiquet en curs, les dades de catàleg de productes o les promocions, i s'han d'anar reflectint de forma permanent aquí. En aquest nivell de dades hi ha el detall de les línies de cada tiquet (producte, quantitat, import, etc...) , els detalls del cobrament de cada tiquet (efectiu, VISA, etc...) a mida que va generantse i, finalment, els paràmetres no fixes com els missatges promocionals, les dades de facturació, etc...

4.7.1.2 Nivell intermediari o caixa central

En aquest nivell, ubicat dintre de la xarxa local de botiga, és on s'emmagatzemen les dades provinents de la base de dades remota per ser transferides al TPV. També és on es mantenen els paràmetres locals de tots els TPV, que posteriorment han de ser distribuïts als diferents terminals. Normalment és un TPV central o un lloc de treball amb orientació ofimàtica el que té aquesta responsabilitat. Per un altra banda, a aquesta base de dades arriben també les vendes dels diferents TPV a mida que es van generant.Es pot considerar una mena de servidor proxy que centralitza algunes dades comunes i emmagatzema dades amb poca variabilitat provinents de la central per evitar continues consultes remotes.

4.7.1.3 Nivell remot

Aquest nivell de persistència de dades queda fora de l'abast del projecte però s'ha de tenir en compte per a explicar els processos de venda. En aquest nivell, situat probablement a la central de preus de Kobrabo, es concentren les dades de vendes de tota la xarxa de botigues, un cop consolidades. També és en aquesta base de dades centralitzada on s'emmagatzema el catàleg mestre per ser sincronitzat posteriorment amb cadascuna de les botigues. Cada botiga té un catàleg propi, en funció del número de referències a la venda i del seu nivell de preus, i aquests s'emmagatzemen en aquest nivell per a ser distribuïts o consultats de forma remota.



Al la il∙lustració següent es pot veure diagrama simplificat de la topologia de xarxa d'una configuració de dues botigues, amb TPV's i servidor intermediari cadascuna i una Central amb BD centralitzada.

4.8 Subsistemes del model de negociEn aquest apartat es descriuen els cinc subsistemes del model de negoci, cadascun d'ells encarregantse d'un grup de funcionalitats concretes, i els casos d'ús associats a cadascun d'ells.

Aquesta divisió s'ha fet també en funció de la seva ubicació física a la botiga i per facilitar la seva integració al medi.

Els subsistemes són:

● Subsistema de comunicacions ● Subsistema de cobrament


Il∙lustració : Topologia de xarxa d'una configuració de dues botigues


● Subsistema de seguretat i manteniment● Subsistema de control de caixa

4.9 Subsistema de comunicacionsAquest subsistema és l'encarregat de mantenir la coherència de les dades entre la central de Kobrabo i els terminals punt de venda. Donat que la persistència de dades està estructurada en tres nivells: local, intermedi i remot, s'ha de garantir que els diferents esdeveniments controlats o no controlats que poden produirse (canvis de preus, talls de comunicacions, etc..) no alterin mai la coherència o disponibilitat de les dades.

Atenent al sentit de les dades, hi han dos tipus de comunicacions:● Comunicacions de pujada: Són en la direcció TPVCentral. Permeten que les dades

que generen els diferents TPV de la botiga arribin correctament a la central. Aquestes dades comprenen el detall de les vendes i els resultats dels tancaments comptables.

● Comunicacions de baixada. Són en la direcció CentralTPV. Permeten que qualsevol variació a les condicions de venda (preus, nous formats, nous articles, promocions, etc...) s'apliquin al TPV el més aviat possible.

Atenent al moment que és necessiten les dades, hi han dos tipus de comunicacions:● Programades: són les comunicacions planificades, ja sigui com a part d'un procés

determinat o bé iniciades a una hora determinada. Són previsibles. Per exemple, la recepció diària de preus, l'enviament diari de dades de vendes, etc...

● No programades: són aquelles comunicacions que s'inicien durant la jornada provocades per un esdeveniment no planificat. Per exemple un canvi de preus sobtat, la inhabilitació per a la venda d'un article determinat per motius diversos, l'enviament de les vendes a mitja nit perquè al seu moment no hi havia disponibilitat de comunicacions, etc...

Atenent al contingut de les dades que hi circulen, hi ha varies estructures independents de comunicacions:

● registres de vendes,● dades comptables del tancament de caixa,● registres d'activitat interna del sistema (logs, errors, etc...),● catàleg de preus/promocions,



● informació corporativa (clients, empleats, etc...)● paràmetres globals de venda,● paquets d'actualització de l'aplicació (fora de l'abast d'aquest anàlisi).

Aquest subsistema és accessible únicament pels usuaris amb perfil encarregat o supervisor. Totes les comunicacions programades poden provocarse manualment, comptant que hi hagin dades disponibles per ser transmeses.

4.9.1 Concurrència de les dadesHi ha dos pics de comunicacions importants durant la jornada de treball: l'inici i el tancament de dia.

El primer pic és important pel fet que durant la nit han pogut variar els preus, els formats o qualsevol altra característica dels articles a la venda, a nivell de tota la xarxa de botigues o per a una botiga concreta. Per tant, aquests preus han d'estar disponibles abans d'iniciar el procés de venda per no incórrer en incoherències respecte a la cartelleria, espots publicitaris o catàlegs d'ofertes. Tanmateix, és important planificar correctament el temps disponible per a les botigues entre l'hora d'inici de disponibilitat de les dades remotes, posem, per exemple, les 04:00 a.m., i l'hora d'obertura de la botiga , posem, per exemple, les 08:00 a.m. En aquestes quatre hores, totes les dades han d'estar ja disponibles a les botigues i sense patir cap coll d'ampolla.

4.9.2 Activació dels processos de comunicacionsDepenent del tipus de dades a traslladar, el sistema de comunicacions ubicat a la botiga actua de forma activa o de forma passiva a l'hora d'iniciar els processos. A saber:

Per a qualsevol comunicació que faci referència a l'enviament de dades a la Central, generades a la botiga, com poden ser registres de vendes, registres d'activitat del sistema, etc... és la botiga la que inicia les comunicacions amb la BBDD central.

Hi ha varies justificacions per ubicar la responsabilitat d'iniciar les comunicacions des de la botiga, en aquest cas, en comptes de ser “recollides” per la Central:

1. Actualment el processat de les vendes a la Central es fa en horari nocturn i desprès del tancament de les botigues, però és possible que en un futur les botigues enviïn les dades de vendes en qualsevol moment per conveniència pròpia o be perquè els tancaments s'efectuïn a hores diferents.



2. El creixement de botigues a Kobrabo és exponencial i es vol distribuir d'inici de processos de comunicacions tant com sigui possible.

3. Donada la heterogeneïtat de les xarxes de comunicacions i la dispersió geogràfica dels punts de venda, és responsabilitat de cada subsistema local decidir el moment òptim per iniciar les comunicacions per enviar les dades.

Un dels factors negatius a mig termini d'aquest sistema pot ser la dificultat per controlar la concurrència de dades que arriben a la central. De totes maneres, amb uns algoritmes de retransmissió, en cas de col∙lisió, ben implementats, no ha d'haverhi greus problemes de saturació o de colls d'ampolla.

En cas de canvi de preus, paràmetres de venda o qualsevol dada que es pugui generar a la Central i que afecti a la botiga, és la Central la que inicia l'enviament. Llavors, la botiga queda com un element passiu en aquest procés. Les raons per ferho son varies:

1. El control de la concurrència està totalment controlat, sent possible una planificació en funció del temps i del num. de botigues a comunicar.

2. Es poden fer descàrregues a qualsevol hora, en cas de canvis sobtats a les condicions de venda, sense necessitat de mobilitzar a tota la xarxa de botigues.

Com ja s'ha esmentat, qualsevol de les operacions anteriors també s'ha de poder iniciar manualment per part de la botiga per donar resposta a qualsevol eventualitat fora del calendari de processos.

Actua activament Finalitat de la comunicació

Botiga ● registres de vendes,● dades comptables del tancament de

caixa,● registres d'activitat interna del sistema

(logs, errors, etc...).

Central ● catàleg de preus/promocions,● informació corporativa (clients,

empleats, etc...)● paràmetres globals de venda.

4.9.3 Cas d'ús Enviar Pendents a CentralResum de la funcionalitat general: enviament de les dades ja revisades i consolidades a



la base de dades central.

Paper dins el treball de l'usuari: diària, com a mínim.

Actors: Timer, Encarregat.

Casos d'Ús relacionats: Confirmació d'Enviaments

Precondició: cap

Postcondició: el sistema ha enviat totes les dades pendents de

● registres de vendes,● dades comptables del tancament de caixa,● registres d'activitat interna del sistema (logs, errors, etc...)

pendents i no hi ha cap dada pendent d'enviar.Descripció: el sistema verifica la llista de dades marcades com a revisades i pendents d'enviar i, si existeixen, obre la comunicació amb la central. Un cop establerta, inicia la transferència de dades a la central mitjançant protocols de comunicacions determinats (possiblement FTP) i diposita les dades cada tipus a la taula o repositori remots corresponent.

Observacions:

4.9.4 Cas d'ús Enviar Pendents a BotiguesResum de la funcionalitat general: enviament de les dades actualitzades necessàries per als processos de venda de la botiga.

Paper dins el treball de l'usuari: nocturn, com a mínim.

Actors: Central, Encarregat.

Casos d'Ús relacionats: cas d'Ús Activació de Canvis

Precondició: cap

Postcondició: el sistema té les dades actualitzades referents a:

● catàleg de preus/promocions,● informació corporativa (clients, empleats, etc...).

Descripció: el sistema central connecta amb el nivell de persistència intermediari, mitjançant protocols de comunicacions determinats (possiblement FTP) i diposita les dades actualitzades.



Observacions:

4.9.5 Cas d'ús Activació de CanvisResum de la funcionalitat general: revisió i activació de les dades provinents de la Central.


Actors: Encarregat, Central.

Casos d'Ús relacionats:

Precondició: cap

Postcondició: el sistema s'ha actualitzat amb noves dades i aquestes han sigut posades a disposició del TPV.

Descripció: l'encarregat pot visualitzar una llista de tots els canvis amb respecte al que hi ha actiu a la botiga. Aquests canvis poden incloure modificacions de qualsevol dada referent als articles a la venda tal com preus, descripcions, descomptes, altes, baixes o promocions. També poden incloure canvis a les dades corporatives com baixes d'empleats o bé canvis en la configuració general de la botiga així com canvis al tiquet imprès.

Un cop l'encarregat ha sigut informat dels canvis que s'activaran, aquest ha d'activarlos de forma expressa. A partir d'aquest moment els canvis ja són efectius als TPV.

Observacions: la raó per la qual aquest procés no es desenvolupa 100% automàtic és per la tolerància a errors humans ja que, en cas contrari, qualsevol canvi que s'activés de forma accidental a la Central arribaria als TPV sense cap control humà previ. Tot i que això donaria certa automatització, el risc és massa elevat per l'estalvi de temps que comporta.

També, donat el baix volum de les dades que es traslladen a la botiga (de l'ordre de KB.), els canvis sempre són totals i no incrementals. És a dir, que si un dia no s'actualitzen les dades per motius diversos, al dia següent les dades que arriben inclouen els canvis del dia anterior, ja que cada dia és trasllada una “foto” del que ha d'haverhi a la botiga. Per a més informació consultar l'estimació del volum de dades a l'annex d'aquest projecte.

4.9.6 Cas d'ús Confirmació d'EnviamentsResum de la funcionalitat general: revisió de les dades de vendes que estan pendents de ser enviades a la central.




Actors: Encarregat, Central.

Casos d'Ús relacionats: Enviar pendents a central.

Precondició: hi ha enviaments pendents.

Postcondició: el sistema no té cap dada pendent de revisar i totes les dades estan llestes per a ser enviades.

Descripció: l'encarregat visualitza un llistat, corresponent als blocs de dades de les jornades que han sigut generades pels TPV, ja consolidades i tancades, i que encara estan pendents d'enviar a Central. Aquest pot visualitzar el detall tant de les vendes com del resultat de l'arqueig de caixa. Un cop verificades pot iniciar directament el procés d'enviament o bé pot marcarles per a fer l'enviament de forma temporitzada a una hora concreta, per blocs o per tots a l'hora.

Observacions: les dades de vendes s'han de verificar de forma visual abans de ser enviades a la central, donat que és el darrer punt de control abans d'integrarles a la base de dades remota. En cas d'un error humà o tècnic (proves, manteniment incorrecte, mal ús, errada, etc...) les dades poden ser “detingudes” i corregides per medis tècnics abans que tinguin un impacte de difícil resolució a la comptabilitat, un cop integrades a la base de dades remota.

4.10 Subsistema de cobramentAquest subsistema forma part del nucli central de l'aplicació i és responsable de garantir la transacció comercial entre el client i el comerç així com també algunes funcions auxiliars relacionades. La funció principal d'aquest subsistema és la de rebre la introducció d'articles pels principals perifèrics de captació (teclat, escànner, pantalla tàctil, etc...) identificarlos, valorarlos i imprimirlos. Aquest també ha de gestionar la totalització de l'import del tiquet i el procés de cobrament per qualsevol medi vàlid (efectiu, tarja de crèdit, vals de descompte, etc...).

4.10.1 Cas d'ús Enregistrar un ArticleResum de la funcionalitat general: s'introdueix un article al sistema de cobrament i aquest el valora i l'enregistra.

Paper dins el treball de l'usuari: és un dels casos d'ús mes freqüents all llarg de la



jornada. Com a mínim un per tiquet.

Actors: Caixer, Encarregat.

Casos d'Ús relacionats: obertura de tiquet, tancament de tiquet, lectura per escànner, identificació per teclat.

Precondició: ha d'haverhi un tiquet iniciat i pendent de tancar. Ha d'haverhi un producte a la cua de productes pendents d'enregistrar. La compra d'aquest producte encara no ha estat enregistrada.

Postcondició: l'article ja ha sigut identificat, valorat i incorporat al tiquet en curs. S'ha generat , com a mínim, una línia de tiquet.

Descripció: el caixer agafa físicament un producte de la cua de productes pendents de cobrar i l'identifica al sistema mitjançant teclat o escànner. El sistema incorpora la referència de l'article al tiquet en curs i calcula l'import resultant segons els següents casos:

● PVP directe de l'article si aquest és unitari,

● PVP multiplicat per la quantitat d'articles si el caixer afegeix manualment una quantitat superior a 1 (cas de varis articles iguals al mateix temps),

Finalment, la línia és afegida al tiquet i el client és informat mitjançant el visor de l'import de la línia.

Observacions: La introducció d'un article pot ser per diversos medis d'entrada; el teclat, l'escànner o per una cerca.

4.10.2 Cas d'ús Iniciar un TiquetResum de la funcionalitat general: s'inicia un bloc de cobrament d'articles adreçat a un client.

Paper dins el treball de l'usuari: és imprescindible per a poder cobrar articles.

Actors: Client, Caixer, Encarregat.

Casos d'Ús relacionats: Tancament de Tiquet, Enregistrar un Article.

Precondició: ha d'haverhi un client a caixa amb articles pendents de cobrar que sol∙liciti el servei. El TPV no pot estar al mode d'enregistrament d'articles (veure cas d'ús relacionat). El calaix portamonedes ha d'estar tancat.

Postcondició: s'ha iniciat un tiquet i el sistema está esperant l'enregistrament d'articles



pels perifèrics d'entrada.

Descripció: quan un client arriba al TPV amb articles pendents de cobrar, el caixer inicia la operació de crear un nou tiquet, seleccionant l'ordre corresponent a la interfície. Llavors el sistema enregistra la data, hora, caixer, TPV i client identificat, si s'escau, i queda a l'expectativa de que s'inicii el proces d'enregistrament d'articles.

Observacions:

4.10.3 Cas d'ús Totalitzar un TiquetResum de la funcionalitat general: finalitza un bloc de cobrament d'articles adreçat a un client i s'emet un total calculant totes les possibles variables del mateix (descomptes, promocions, etc...).

Paper dins el treball de l'usuari: normalment aquest procés està relacionat amb el tancament de tiquet. És imprescindible aquest procés per què el client pugui abandonar el TPV amb els seus articles.

Actors: client, caixer.

Casos d'Ús relacionats: Iniciar un Tiquet, Enregistrar un Article, Tancar una Transacció.

Precondició: ha d'haverhi un tiquet obert. El caixer ha de saber si el client és un client identificat. És a dir, si té tarja de client o similars.

Postcondició: les línies del tiquet han estat sumades i ha estat emès un import total corresponent als articles que estan a la zona d'articles ja identificats. El sistema està esperant ordre de finalitzar el tiquet o retrocedir.

Descripció: el client demana saber l'import de la compra o bé no hi ha més articles per cobrar a la cua d'entrada d'articles. Llavors el caixer selecciona l'opció corresponent a total de tiquet i el TPV calcula el següent:

● Suma dels imports de totes les línies que componen el tiquet,

● aplicació, si s'escau, de descompte per ser client amb dret a descompte,

● aplicació, si s'escau, de descomptes promocionals per famílies d'articles, etc....

Seguidament el TPV informa al client i al caixer d'aquest import i el presenta al client pel visor i al caixer per pantalla.

Observacions: aquest procés es pot retrocedir i seguir amb el cobrament d'articles.



4.10.4 Cas d'ús Tancar TransaccióResum de la funcionalitat general: finalitza la transacció entre el client i Kobrabo mitjançant el pagament de l'import corresponent als articles que el client ha seleccionat.

Paper dins el treball de l'usuari: és un procés que implica la resolució de la compra, normalment al final de cada tiquet iniciat.

Actors: Caixer, Client, Encarregat.

Casos d'Ús relacionats: Iniciar un Tiquet, Enregistrar un Article, Totalitzar un Tiquet, Cobrament TEF.

Precondició: el sistema està en l'estat de totalització de tiquet.

Postcondició: el tiquet i tots els seus components (línies, dades, etc...) queden enregistrats i consolidats al sistema. El sistema executa la funció d'iniciar un nou tiquet per defecte.

Descripció: l'usuari informa al sistema del medi de pagament en funció de les preferències del client.

En cas de metàl∙lic:

1. El client fa el pagament amb l'import just o amb més import del que es necessita. Si l'import subministrat pel client és inferior, el caixer ha de rebutjar el pagament i demanar més import. Si el client no pot satisfer l'import, el caixer informarà al sistema de que la transacció no pot ser efectuada. En aquest cas la transacció no s'ha efectuat i per tant el sistema, prèvia confirmació, retrocedirà totes les línies (generantles amb import negatiu) i tancarà automàticament el tiquet amb l'import a zero.

2. El caixer informa al sistema de l'import subministrat pel client.

3. El sistema obre el calaix portamonedes i informa al caixer del canvi a tornar al client, que pot ser zero o superior.

4. El caixer torna al client l'import informat pel sistema, agafant efectiu del calaix portamonedes.

5. El caixer tanca el calaix portamonedes i informa al sistema de que la transacció ha sigut efectuada amb èxit.

6. El sistema imprimeix un tiquet en paper per al client amb el detall de la compra.

En cas de pagament amb tarja de crèdit:



1. El sistema demana que el caixer passi la tarja pel lector i esperi confirmació.2. El caixer identifica de forma visual la validesa del DNI. 3. El caixer passa la tarja per la ranura del lector i el sistema de TEF prova de gestionar

el cobrament. Si aquest és correcte, es tanca el compte automàticament i s'imprimeix el tiquet en paper. En cas contrari, el sistema retorna a l'inici de la funció de selecció de tipus de pagament.

Observació 1: aquest procés NO es pot retrocedir un cop finalitzat. En cas de voler anul∙lar el tiquet, consultar el cas d'ús Devolució d'Articles.

Observació 2: en cap cas s'admet més d'un tipus de pagament combinat.

4.10.5 Cas d'ús Devolució d'ArticlesResum de la funcionalitat general: s'efectua un cobrament “invers” o, el que és el mateix, es torna a recomprar els articles al client al mateix import que se li van vendre al seu moment.

Paper dins el treball de l'usuari: esporàdic. Aquesta operació s'acostuma a fer a la caixa central per motiu d'una devolució d'articles per part del client.

Actors: Empleat.

Casos d'Ús relacionats: Totalitzar Tiquet, Tancar Transacció.

Precondició: el tiquet a rectificar ha d'existir a la base de dades i ha d'estar disponible. Els articles a retornar han d'existir al tiquet a rectificar. La quantitat dels articles a retornar no poden superar en quantitat a la dels mateixos articles enregistrats al tiquet original.

Postcondició: el sistema ha generat un tiquet amb les línies en negatiu referents als articles que s'han retornat, recuperant els preus vigents el dia de la venda dels articles.

Descripció:

1. L'usuari selecciona la opció d'anul∙lació de tiquet.

2. El sistema demana la data, el número de tiquet i l'import del tiquet a rectificar.

3. El sistema demana a l'usuari els articles que s'han de retornar i el motiu: devolució voluntària o error de caixa.

4. L'usuari informa al sistema dels articles a retornar mitjançant una pantalla d'edició on pot editar i rectificar les dades referents a les columnes codi, quantitat i motiu.



5. Dinàmicament, el sistema recupera els preus al moment de la venda i calcula la diferència entre els articles retornats i els que van ser adquirits.

6. El sistema informa de l'import a retornar al client.

7. L'usuari retorna al client l'import corresponent i informa al sistema.

8. L'usuari selecciona la opció de Totalitzar Tiquet i a partir d'aquí el sistema tracta el procés com un tiquet convencional.

Observacions: Aquesta funció es pot donar, bàsicament, en dos casos: un error del caixer o bé una devolució de producte per part del client.

Exemple de devolució d'articles

Un client arriba a la caixa central amb el següent tiquet (simplificat):

Article Quantitat Import Total línia

A 5 1.25 6.25

B 4 3.50 14.00

C 3 5 15.00

D 12 2 24.00

E 1 2.33 2.33

TOTAL TIQUET 61.58

El client vol retornar 2 unitats de l'article A i 3 unitats de l'article B. També demostra que a la seva cistella té només un article C i en canvi li han cobrat tres unitats.

La informació que ha de rebre el sistema respecte a les operacions que s'han d'efectuar és:

Article Quantitat Motiu

A 2 Retorn

B 3 Retorn

C 2 Error(Nota: en cas de que sigui un error a favor del client, cas improbable, la quantitat és en negatiu)El sistema genera dinàmicament el tiquet següent, corresponent a l'import a percebre per



part del client:Article Quantitat Import Total línia

A 2 1.25 2.50

B 3 3.50 10.50

C 2 5 10.00

TOTAL TIQUET 23.00

4.10.6 Cas d'ús Rectificar Línies de TiquetResum de la funcionalitat general: anul∙lació i/o rectificació de línies de tiquet abans de tancar la transacció.

Paper dins el treball de l'usuari: habitual dintre del cobrament d'un tiquet.

Actors: Caixer.

Casos d'Ús relacionats: Tancar Transacció, Enregistrar Articles.

Precondició: el sistema està a l'opció d'Enregistrar Articles.

Postcondició: el camp 'quantitat' de les línies del tiquet ha sigut modificat i el sistema ha enregistrat una línia de tiquet amb quantitat negativa i una nova línia de tiquet amb la quantitat correcta.

Descripció:

● El caixer selecciona l'opció d'editar línies i fa les modificacions adients al camp 'quantitat' de cada línia. Si la quantitat de la línia és zero, la línia és eliminada del tiquet.

● El caixer confirma els canvis.

Observacions: les línies de tiquet s'enregistren al disc un cop són creades pel sistema. Per aquest motiu, un cop enregistrades al disc, ja no haurien de ser eliminades i és necessària una línia d'anul∙lació per tal de que no tinguin cap impacte en el resultat del tiquet.

4.10.7 Cas d'ús Cobrament TEFResum de la funcionalitat general: operació de transacció de fons entre l'entitat emissora del cobrament (la botiga) i la entitat receptora del mateix (el client).

Paper dins el treball de l'usuari: necessari per qualsevol pagament amb tarja de crèdit.



Actors: Caixer, TEF.

Casos d'Ús relacionats: Tancar Transacció.

Precondició: el sistema ha d'estar al cas d'ús Tancar Transacció.

Postcondició: s'ha emès un càrrec a compte del client i la entitat ha tornat una resposta.

Descripció:

● El caixer selecciona la opció de pagament per tarja de crèdit.

● El sistema informa al caixer de que ha de passar la tarja de crèdit per la ranura del lector de targes.

● L'agent TEF integrat rep les següents dades:

○ Import a carregar,

○ Nº de tarja de crèdit,

○ nom del titular,

○ data de caducitat de la tarja.

● Amb aquestes dades, el sistema TEF genera un paquet de dades i l'envia al sistema gestor (remot) de cobraments corresponent.

● El sistema gestor intenta efectuar el càrrec al banc i retorna una resposta informant agent TEF local del resultat de la transacció.

● Al cas de que el càrrec s'hagi efectuat correctament, l'agent TEF informa al sistema i aquest emet dues còpies del comprovant de la transacció perquè el client en signi una.

● El caixer informa al sistema de que el client ha signat correctament i el sistema dona la transacció per finalitzada.

Observacions: cap.

4.10.8 Cas d'ús Pagament de CaixaResum de la funcionalitat general: operació que enregistra una despesa de la botiga, en efectiu, feta des de la caixa per motiu d'un pagament, fruit d'un servei o compra no previstos.



Paper dins el treball de l'usuari: esporàdic.


Casos d'Ús relacionats: cap.

Precondició: cap.

Postcondició: el sistema ha enregistrat una sortida de diners de caixa i una entrada d'un document del mateix import que justifica la despesa.

Descripció:

● L'usuari selecciona l'opció corresponent a la pantalla principal de cobrament.

● El sistema demana a l'usuari les següents dades obligatòries:

○ Identificador i contrasenya del supervisor que ha de validar el pagament.

○ Import del pagament.

○ Motiu del pagament (compra estris neteja, servei extern, etc...) entre una llista de conceptes ja fixats.

○ Documentació adjunta al pagament com factura, comprovant, albarà valorat, etc...

● L'usuari prem acceptar i el TPV enregistra les dades, restant aquest import de l'efectiu de caixa.

Observacions: cap.

4.11 Subsistema de seguretat i mantenimentAquest subsistema és l'encarregat de gestionar el manteniment de dades locals de la botiga que no estan determinades per part de la central. Aquestes dades poden ser usuaris, TPV's de la botiga amb les seves dades de xarxa (IP) o característiques tècniques i qualsevol informació que pugui diferenciar una botiga amb la resta de botigues de la cadena i que es mantingui localment.

Aquest subsistema també és responsable de la seguretat que envolta a les operacions de cobrament, com són la validació d'usuaris o els controls de caixa necessaris per garantir un bon ús del sistema.



4.11.1 Cas d'ús Alta d'UsuariResum de la funcionalitat general: addicció d'usuaris al sistema de cobrament.

Paper dins el treball de l'usuari: eventual.

Actors: Encarregat.

Casos d'Ús relacionats: Baixa i Consulta/modificació d'usuaris.

Precondició: el num. d'empleat de l'usuari existeix a la base de dades general d'empleats. L'usuari no existeix al sistema local.

Postcondició: el sistema enregistra un nou usuari, vinculat a un empleat existent.

Descripció:

1. L'encarregat selecciona l'opció de menú corresponent.

2. Selecciona el número d'empleat a la base de dades d'empleats i el sistema mostra el nom de la persona.

3. L'encarregat informa de les següents dades al sistema:

○ perfil (caixer o encarregat),

○ horari de treball,

○ identificador per entrar al sistema,

○ activació del compte (activat per defecte),

○ canviar contrasenya al proper inici de sessió (activat per defecte).

Observacions: a partir del moment que es confirma l'alta, les dades és propaguen per als TPV's i aquest usuari ja pot utilitzar el sistema.

4.11.2 Cas d'ús Baixa d'UsuariResum de la funcionalitat general: eliminació d'usuaris del sistema de cobrament.

Paper dins el treball de l'usuari: eventual.

Actors: Encarregat.

Casos d'Ús relacionats: Alta i Consulta / Modificació d'Usuaris.

Precondició: l'usuari existeix al sistema local.



Postcondició: l'usuari ja no existeix al sistema local.

Descripció:

● L'encarregat selecciona l'opció de menú corresponent.

● El sistema mostra una llista dels usuaris del sistema.

● L'encarregat selecciona un usuari i selecciona l'opció d'eliminar.

● El sistema demana confirmació de l'operació.

● El sistema elimina l'usuari del sistema.

Observacions: si al moment de la baixa l'usuari està utilitzant el sistema, aquest és actiu fins que faci la propera validació. NOTA: les baixes son lògiques per tal de que no quedin trencades les relacions entre taules.

4.11.3 Cas d'ús Modificació d'UsuariResum de la funcionalitat general: Modificació de les dades dels usuaris del sistema de cobrament.

Paper dins el treball de l'usuari: Eventual.

Actors: Encarregat.

Casos d'Ús relacionats: Alta i Baixa d'usuaris.

Precondició: L'usuari existeix al sistema.

Postcondició: Les dades de l'usuari han sigut modificades al sistema.

Descripció:

● L'encarregat selecciona l'opció de menú corresponent.

● El sistema mostra una llista dels usuaris del sistema.

● L'encarregat selecciona un usuari i selecciona l'opció de modificar.

● El sistema mostra un formulari amb les dades de l'usuari.

● L'encarregat modifica les dades següents:

○ perfil (caixer o encarregat),

○ horari de treball,

○ activació del compte (activat per defecte),



○ canviar contrasenya al proper inici de sessió.

Observacions: Si al moment de la modificació de l'usuari, aquest esta utilitzant al sistema, els canvis no son efectius fins que faci la propera validació.

4.11.4 Cas d'ús Iniciar SessióResum de la funcionalitat general: Verifica que l'identificador d'usuari i la contrasenya introduïts al sistema siguin correctes i permet a l'usuari iniciar una sessió de treball. També enregistra el nombre d'intents erronis d'accedir.

Paper dins el treball de l'usuari: és el primer cas d'ús quan un usuari vol treballar amb l'aplicació o bé quan la màquina ha sigut prèviament bloquejada.


Casos d'Ús relacionats: Renovar contrasenya.

Precondició: l'usuari ha d'estar prèviament donat d'alta al sistema i amb permisos per a iniciar sessió.

Postcondició: el sistema ha reconegut l'usuari i li ha aplicat els permisos i restriccions que li atorga el seu perfil, situantlo al punt d'entrada definit.

Descripció: El sistema demana a l'usuari l'identificador i contrasenya. Llavors, el sistema comprova que l'usuari està donat d'alta al sistema i verifica que la contrasenya subministrada correspongui a la d'aquest usuari. En cas afirmatiu, el sistema consulta el perfil de l'usuari i li dona un punt d'entrada a l'aplicació. Al cas que l'usuari no existeixi el sistema, aquest tornarà a demanarlo els cops necessaris. En cas de que l'usuari existeixi al sistema però es facin tres intents incorrectes de contrasenya, el sistema aplicarà una penalització de temps consistent en deu segons d'espera i tornarà a iniciar el cicle. En aquest cas també es deixarà constància d'aquest fet al registre de sistema.

Observacions: No s'aplica bloqueig de compte ja que la disponibilitat del sistema esta per sobre de la seva seguretat.

4.11.5 Cas d'ús Renovar contrasenyaResum de la funcionalitat general: Permet a l'usuari canviar la seva contrasenya.

Paper dins el treball de l'usuari: esporàdic.

Actors: Empleat.



Casos d'Ús relacionats: Manteniment d'usuaris.

Precondició: El compte d'usuari ha d'existir.

Postcondició: L'usuari te una nova contrasenya diferent de l'anterior.

Descripció: El sistema demana a l'usuari la seva antiga contrasenya i dos cops la nova contrasenya. Si la contrasenya antiga és correcta i les dues noves contrasenyes son iguals entre elles i diferents de la primera, el sistema enregistra la nova contrasenya per al usuari.

Observacions:

4.11.6 Cas d'ús Bloqueig de CaixaResum de la funcionalitat general: la caixa queda bloquejada a nivell de programari, tot esperant la identificació d'un usuari per tal de poder continuar amb la operativa.

Paper dins el treball de l'usuari: aquest cas d'us pot ser iniciat per un usuari de forma voluntària o mitjançant l'acció d'un “salvapantalles”.

Actors: Caixer, Encarregat, Timer.

Casos d'Ús relacionats: Verificar Entrada

Precondició: cap

Postcondició: el sistema no pot ser utilitzat i queda a l'espera de verificar una entrada d'usuari.

Descripció: L'usuari acciona la funció de bloqueig de caixa (mitjançant un botó o una opció de menú) o bé el sistema no ha rebut cap interacció d'usuari durant un temps determinat. Llavors el sistema queda en funció de Verificar Entrada, tot esperant la entrada del mateix usuari que ha iniciat aquest cas d'ús o bé esperant una entrada amb perfil superior. Un cop succeït l'anterior, i essent l'entrada correcta, el sistema retorna al punt on estava abans de l'inici de la funció.

Observacions: Un perfil superior a caixer pot ser un perfil encarregat.

4.11.7 Cas d'ús Finalitzar SessióResum de la funcionalitat general: un usuari finalitza la seva sessió de cobrament (canvi de torn, descans, etc...) i el TPV pot ser utilitzat per qualsevol altre caixer.

Paper dins el treball de l'usuari: aquest cas d'ús es dona un cop al dia com a mínim, per



donar pas al tancament.

Actors: caixer

Casos d'Ús relacionats: Verificar Entrada

Precondició: el sistema no pot estar iniciant un tiquet, ni cobrant un tiquet, ni totalitzant un tiquet, ni tancant un tiquet.

Postcondició: el sistema es troba en el seu punt inicial i esperant una entrada d'usuari.

Descripció: l'usuari acciona la funció corresponent mitjançant una tecla i/o una opció de menú i el sistema retorna al punt d'entrada.

Observacions: Aquest cas d´ús seria l'equivalent a un logout.

4.12 Subsistema de control de caixaEl sistema de control de caixa és el responsable de garantir en tot moment la coherència entre l'efectiu de caixa i les dades que el programari reflecteix. Controla l'obertura i el tancament de caixa, els controls aleatoris durant la jornada de treball i tots els processos relacionats.

4.12.1 Cas d'ús Informar d'EfectiuResum de la funcionalitat general: control de l'efectiu que hi ha a la caixa mitjançant l'acció de contar manualment el contingut del calaix portamonedes.

Paper dins el treball de l'usuari: és una acció necessària per a poder finalitzar el dia o per a canviar el torn del caixer.

Actors: Caixer

Casos d'Ús relacionats: Arqueig de caixa

Precondició: el sistema no pot estar iniciant un tiquet, ni cobrant un tiquet, ni totalitzant un tiquet, ni tancant un tiquet.

Postcondició: al sistema hi ha una anotació de l'efectiu que hi ha a la caixa en un moment donat.

Descripció:

● El caixer selecciona l'opció de balanç de caixa a la pantalla o a la tecla adient.



● El sistema obre el calaix portamonedes.

● El caixer compta l'efectiu i informa al sistema mitjançant el formulari adient.

● El caixer confirma l'operació.

Observacions: aquest cas d'us és iniciat per la necessitat de justificar que un caixer abandona la caixa fentse responsable de l'efectiu que hi ha a la mateixa fins a aquell moment.

4.12.2 Caso d'ús Arqueig de CaixaResum de la funcionalitat general: control arbitrari que efectua l'encarregat per verificar la coherència entre l'efectiu i les vendes enregistrades.

Paper dins el treball de l'usuari: com a mínim, un cop al dia al fer el tancament.

Actors: Encarregat.

Casos d'Ús relacionats: Informar d'Efectiu, Tancament de Caixa.

Precondició: el sistema ha d'haver enregistrat un o més informes d'efectiu.

Postcondició: cap, al ser una consulta.

Descripció: l'encarregat selecciona l'opció de menú corresponent i informa al sistema del número de TPV que vol processar. Llavors, el sistema suma els imports dels tiquets i els moviments que s'han generat en aquest TPV i els compara amb els informes d'efectiu dels caixers que l'han utilitzat. Finalment, emet una quantitat que és la diferència de caixa.

Observacions: S'adjunta un exemple en forma de guió per il∙lustrar la importància d'aquest cas d'ús.

1. Un caixer inicia el dia a les 8:30 h. amb 300 euros al calaix portamonedes.

2. Llavors enregistra cobraments fins a les 14:30 h. per valor de 1.000 euros.

3. Abans d'abandonar la caixa el caixer compta 994 euros d'efectiu i informa al sistema.

4. Un segon caixer enregistra cobraments de les 14:30 h. fins a les 20:30 h. per valor de 1200 euros.

5. Al finalitzar la jornada i abans d'abandonar la caixa, aquest segon compta 2.189 euros i informa al sistema.

6. A la caixa central, l'encarregat detecta que els ingressos per vendes pugen a 2.200



euros.

7. L'encarregat, consultant les dades a posteriori (consultar els casos d'ús de tancament de caixa i control d'efectiu) detecta que falten a la caixa un total de 11 euros fins a les 20:30 h. Amb les dades dels arquejos de cada torn, detecta que el primer caixer va patir un desquadri de 6 euros. Per tant, el segon caixer únicament és responsable del descuadri de 5 euros corresponents al seu torn.

4.12.3 Caso d'ús Tancament de CaixaResum de la funcionalitat general: Finalitza la jornada comptable d'un TPV, es consoliden les vendes i es comptabilitza la recaptació de caixa del dia.

Paper dins el treball de l'usuari: Un sol cop al dia.

Actors: Encarregat.

Casos d'Ús relacionats: Arqueig de caixa, Confirmació d'Enviaments.

Precondició: ha d'existir un Inici de Dia.

Postcondició: el sistema queda finalitzat i ja no es poden fer més vendes a la botiga. S'han enregistrat les dades necessàries per generar un assentament de caixa i s'han consolidat les vendes de la jornada. S'ha enregistrat i tancat una jornada juntament amb la seva recaptació. Les dades estan preparades per ser marcades per a enviar a la central.

Descripció: L'encarregat selecciona l'opció de menú corresponent i informa al sistema del TPV que vol tancar. Llavors, el sistema genera un arqueig de caixa automàtic que és el que queda enregistrat.

Observació 1: El flux d'execució ha de facilitar la transició fins el cas d'ús de Confirmació d'Enviaments donat que és el següent pas natural.

Observació 2: Possiblement seria important obligar al procés a verificar si abans s'ha efectuat un arqueig de caixa, ja que aquest procés és irreversible.

4.12.4 Caso d'ús Inici de DiaResum de la funcionalitat general: S'inicia la jornada comptable d'un TPV per emmagatzemar dades de vendes.

Paper dins el treball de l'usuari: Un sol cop al dia o jornada.



Actors: Encarregat.

Casos d'Ús relacionats: Identificació

Precondició: la darrera operació que el TPV ha d'haver efectuat és un tancament de caixa.

Postcondició: el sistema queda inicialitzat i llest per iniciar els cobraments.

Descripció: L'encarregat selecciona l'opció de menú corresponent i s'identifica. Llavors informa al sistema que vol iniciar el dia. El sistema inicialitza les dades i estructures i prepara el sistema per iniciar el cobrament.

Observacions: cap.

4.12.5 Cas d'ús Retirada d'EfectiuResum de la funcionalitat general: funcionalitat que s'utilitza per “moure” una quantitat d'efectiu del calaix fins a una altra ubicació i s'informa al sistema d'aquest fet.

Paper dins el treball de l'usuari: Es fa servir quan la recaptació és molt alta i s'acumulen massa diners a caixa.


Casos d'Ús relacionats:

Precondició: cap

Postcondició: Al sistema hi ha una anotació d'una retirada d'efectiu del calaix portamonedes.

Descripció:

1. El caixer avisa a l'encarregat que ha de fer una retirada d'efectiu.

2. L'encarregat es persona a la caixa.

3. El caixer selecciona l'opció adient al sistema.

4. El sistema obre el calaix portamonedes.

5. El caixer recull i compta els diners a retirar.

6. El caixer informa al sistema dels diners enretirats de la caixa.

7. El sistema imprimeix un comprovant per al caixer , que ha de signar l'encarregat i un altre per a l'encarregat que ha de signar el caixer.



8. Finalment el caixer informa al sistema de que l'operació s'ha efectuat amb èxit.

Observacions: L'efectiu retirat s'acostuma a traslladar a la caixa forta de la pròpia botiga.

4.12.6 La gestió de perifèricsEl subsistema de Seguretat i Manteniment també és l'encarregat de mantenir i comunicar el programari amb els diferents dispositius físics o perifèrics que composen el sistema. Donada la gran dependència que té el programari del maquinari i la potencial diversitat d'aquest, es creu convenient mantenir les seves característiques específicament des del programari i no delegar la responsabilitat d'aquesta tasca a una capa inferior com podria ser el sistema operatiu.

Per exemple, a un determinat TPV pot haverhi una impressora de tiquets tèrmica de 40 columnes, un visor de dues línies per 40 caràcters i un escànner per port sèrie RS232. A un altre TPV de la mateixa botiga pot haverhi una impressora de tiquets matricial IBM de 44 columnes, un visor de 8 línies i 42 caràcters cadascuna i un escànner per port USB. Això pot fer que es necessiti un tractament de la informació d'entrada i sortida totalment diferent, tant per les seves característiques físiques com pel format de les dades que lliuren o que han de rebre.

4.12.7 Cas d'ús Llegir un EANResum de la funcionalitat general: Es rep una dada per l'escànner i aquest la fa arribar al sistema en forma de codi d'article o codi EAN.

Paper dins el treball de l'usuari: És la forma d'entrada mes habitual d'un article al sistema.

Actors: Caixer

Casos d'Ús relacionats: Enregistrar un article

Precondició: l'escànner està actiu i correctament inicialitzat.

Postcondició: el sistema ha enregistrat un codi de barres o codi EAN d'un article.

Descripció: El caixer situa davant de l'escànner un article , enfocant el codi EAN al làser, i aquest és enregistrat per l'escànner. L'escànner emet una senyal audible o visual que confirma aquest fet i fa arribar al sistema el codi intern de l'article o bé el seu codi EAN.

Observacions: No s'ha definit



4.13 La interfície d'usuari Una de les característiques importants que el projecte ha de tenir en compte és la interacció humana amb el sistema. No es tracta solament de dissenyar una interfície d'usuari amigable on es puguin seleccionar les diferents opcions de forma àgil i eficaç, sinó que també és vital que tant els permisos (affordances) com les restriccions siguin clars i inequívocs, tot guiant a l'usuari pels processos que li estan permesos sense deixar lloc a l'ambigüitat, als dubtes o als errors. Per tant, s'ha de tenir molt en compte que l'usuari típic d'aquest sistema és més proper a l'usuari de maquinària industrial que a l'usuari d'ofimàtica, en el sentit que en molts cassos són persones expertes en l'ofici però no en la tecnologia subjacent a aquest.

Tot i que a la fase de disseny s'aprofundeix més en certs aspectes funcionals de la interfície gràfica d'usuari i es dissenyen els prototipus de la mateixa, en aquesta fase s'han de tenir en compte una sèrie de requeriments, fruit de les necessitats del client anteriorment esmentades:

1. Agilitzar el pas per caixa per reduir el temps d'espera a les cues i per augmentar el número de clients per unitat de temps.

2. Automatitzar i ajudar al procés de venda.

3. Fer el sistema més segur i tolerant a errors humans o tècnics.

4. Permetre un procés de formació i adaptació ràpid a usuaris sense experiència prèvia.

Tot seguint les directrius anteriorment exposades, el sistema comptarà amb les següents característiques.

4.13.1 Teclat físic amb tecles directesLa interfície del sistema que s'ha de dissenyar ha de reduir al màxim el golf d'execució. Per tant, les funcions més repetitives durant l'operativa de cobrament, llistades a continuació, han de ser activades amb tecles físiques directes per tal d'agilitzar el pas per caixa.

Pot haverhi més funcions què durant les fases posteriors d'aquest projecte es decideixi incloure en aquesta categoria. Una referència aproximada per saber quines funcions són d'alta disponibilitat i necessiten ser incloses en aquesta categoria seria la de distingir aquelles funcions que potencialment s'utilitzen com a mínim un cop per cada línia de tiquet. El grup de tecles numèriques es considera un sol grup compacte.

També es poden incloure algunes d'aquelles funcions que s'utilitzen sempre un cop per



cada tiquet.

Finalment, també es poden incloure aquelles funcions que s'utilitzin eventualment però que per la seva immediatesa requereixin un accés immediat.

Algunes d'aquestes poden ser:

● Introduir un codi numèric (num pad),

● rectificar una entrada (backspace),

● anul∙lar la darrera línia complerta (escape),

● confirmar una acció (enter),

● cursors de direcció,

● bloquejar la caixa,

● seleccionar el tipus de pagament (tarja de crèdit o efectiu),

● tancar un tiquet,

● iniciar un tiquet,

● tecla del pànic, descrita a l'apartat corresponent.

4.13.2 Pantalla tàctilAquest sistema està dissenyat per a ser utilitzat amb pantalla tàctil tot i que per motius d'ergonomia les principals funcions han d'anar habilitades també per teclat físic.

El sistema ha de permetre que qualsevol funció es pugui executar en una pantalla tàctil, independentment de que algunes d'aquestes funcions ja estiguin habilitades també per teclat. Això és per motius de disponibilitat i d'agilitat.

Les funcions del sistema no tant repetitives però necessàries, han de ser també accessibles fàcilment, a cada tiquet, i s'han de poder utilitzar durant l'operativa amb tecles directes en pantalla. Algunes d'aquestes funcions poden ser:

● Cerca d'un article per codi numèric,

● cerca d'un article per codi EAN,

● cerca d'un article per aproximació alfanumèrica,

● retirada d'efectiu,



● ...

4.13.3 Sistema auditiuEl sistema auditiu és molt important a un sistema de cobrament d'articles. Aquest sistema ha d'indicar al caixer la diferència entre les operacions correctes i les errònies, sense que aquest hagi de mirar la pantalla cada cop. Aquest, normalment, esta fent operacions repetitives com passar articles per l'escànner o verificant un pagament i no sempre pot tenir la visió orientada a la pantalla.

Dintre del grup sonor de les operacions correctes, el sistema també ha de diferenciar aquestes pel seu tipus. Per exemple, tecla premuda, línia correcta, lectura correcta d'escànner, final d'operació de tiquet, calaix obert, etc... i així guiar al caixer per una seqüència lògica i correcta d'operacions.

Totes aquestes senyals han d'aconseguir una comunicació efectiva amb el caixer permetent que aquest s'assabenti del que passa al sistema però també tenint en compte que el caixer no pot obviar les senyals. A diferència de les visuals, on senzillament pot apartar la vista per descansar, les auditives no son evitables i si no estan ben definides poden representar una molèstia afegida al seu treball.

Finalment, també s'ha de tenir en compte com a factor molt important les percepcions del client, ja que aquest esta present durant tot el procés de cobrament i no coneix el significat de les senyals que li arriben. Per tant, aquestes han de ser mínimes per no crear sensació de “falsos problemes durant la compra”.

Com a directrius per a dissenyar el sistema auditiu s'ha de tenir en compte el següent:

● Sons de duració curta, de freqüències no gaire altes i amb intensitat moderada.

● Màxima orientació de la font de só cap al caixer, evitant al client.

● Es poden utilitzar senyals politòniques, però curtes i amb un màxim de tres tons per senyal.

● Les accions que han de tenir resposta auditiva son únicament aquelles que tinguin un risc d'error alt. Per exemple, una confirmació de pagament TEF, una tecla premuda o una identificació correcta d'article (per l'escànner o pel propi sistema).

● S'ha de tenir en compte que hi ha accions que no necessiten un só de confirmació, donat que van encadenades amb altres que ja les confirmen o bé son final se seqüència. Per exemple, no cal indicar de forma auditiva que s'ha fet la totalització



del tiquet, donat que el caixer fa una pausa obligada tot esperant el pagament i per tant pot consultar la pantalla de forma visual.



5 Fase de dissenyDesprès d'analitzar el model de negoci, els requeriments i l'especificació del sistema TPV2.0 es dona pas a la fase de disseny on l'aplicació pren “cos”. En aquesta comença una aproximació precisa de com es portarà a terme el que anteriorment s'ha definit en línies generals.

5.1 Disseny de la persistènciaEl sistema de persistència esta basat en un model de base de dades relacional.

A l'hora d'implementarlo s'han de tenir en compte els requeriments de disponibilitat i rendiment analitzats en la fase anterior juntament amb el disseny exposat en aquesta fase. Tot això influirà en el tipus de SGBD (Sistema Gestor de Base de Dades) a utilitzar i en els detalls tècnics i funcionals.

5.1.1 Diagrama del model E/R


Il∙lustració : Diagrama d'entitat/relació


Les classes que modelen els perifèrics (visor, impressora, teclat...) han de tenir una permanència local, solament per alguns paràmetres referents a les seves característiques tècniques. Per aquest motiu, aquests no han sigut inclosos al model E/R per tal de ferlo mes entenedor i a mes perquè aquesta permanència es portarà a terme mitjançant un fitxer de text del tipus “properties” i no mitjançant la base de dades relacional.El subsistema TEF queda fora del disseny de la persistència perquè les dades de les transaccions no poden emmagatzemarse localment, segons especifica la llei de Normas de Seguridad de Datos de la Industria de Tarjetas de Pago PCI DSS. Un cop una petició TEF ha quedat resolta, totes les dades de la banda magnètica com el nom del titular, la data de caducitat, el PAN, etc... així com els detalls d'aquesta transacció han de ser eliminats del sistema. Qualsevol consulta futura envers una transacció resolta ha de ser gestionada mitjançant els responsables de la prestació del servei TEF.Tal i com s'ha especificat anteriorment, el sistema de promocions és de tipus no complex. La relació entre article i promoció és M a 1, donat que un article únicament pot estar afectat per una promoció simultàniament. En una segona revisió, a fi d'especificar un sistema de promocions complex, s'ha de tenir en compte que la cardinalitat ha de ser M,N ja que un article podrà llavors estar afectat per mes d'una promoció.

5.1.2 Transformació del model E/R al model relacionalARTICLE (idarticle, promocio, pvp, descripCurta, descripLlarga, dataAlta, isActiu, origen, format, unitatVenda, iva)

on {iva} referencia a IVAon {promocio} referencia a PROMOCIO. Es permeten nuls.

BOTIGA (idBotiga, nom, adreça, tel, fax, cp, capTiquet, peuTiquet, numTpvs )CAIXER (id, codi, responsable, control)

on {codi} referencia a EMPLEATon {responsable} referencia a ENCARREGATon {control} referencia a CONTROLEFECTIU

CLIENTIDENTIFICAT (dni, tipus, puntsAcumulats, dtePreferent)on {dni} referencia a PERSONA

CONTROLEFECTIU (import, data, hora, caixer)on {data, hora} referencia a TANCAMENTon {caixer} referencia a CAIXER

EAN (ean, article, tipus)on {article} referencia a ARTICLE



EMPLEAT (id, codiEmpleat, login, contrasenya, dataAlta, dataBaixa)on {id} referencia a PERSONA

ENCARREGAT (id, codiEmpleat, botiga, subcategoria)on {id} referencia a PERSONAon {codiEmpleat} referencia a EMPLEATon {botiga} referencia a BOTIGA

IVA (id, tipus)LINIATIQUET (ordinal, tiquet, quantitat, article, pvp, dte)

on {tiquet} referencia a TIQUETon {article} referencia a ARTICLE

MOVIMENTCAIXA (import, tiquet, tipus)on {tiquet} referencia a TIQUET

PERSONA (dni, nom, cognoms, data_neixement, nacionalitat, adreça, cp, població, provincia)PROMOCIO (id, botiga, tipus, datainici, datafinal, descompte)

on {botiga} referencia a BOTIGA.TANCAMENT (id, data, hora, responsable)

on {responsable} referencia a ENCARREGATTIQUET (id, tancament, client, caixer, tpv, data, hora)

on {tancament} referencia a TANCAMENT s'admeten nuls,on {client} referencia a CLIENTIDENTIFICAT,on {caixer} referencia a CAIXER,on {tpv} referencia a TPV.

TPV (id, botiga, tipus, ipXarxa)on {botiga} referència BOTIGA.

5.2 Diagrames estàticsA continuació es presenten els diagrames estàtics de classes, agrupats per classes d'entitat, classes de control d'errors o excepcions, classes d'interfície d'usuari i classes d'accés a dades.



5.2.1 Diagrama estàtic de classes

Observacions:

● En aquest diagrama no s'ha modelat cap classe 'Familia' o 'SubFamilia' envers els articles, donat que el manteniment d'articles, les seves relacions i agrupacions jeràrquiques son complexes i queden gestionades a la Central. En aquest anàlisi la família d'un article no afecta a la venda en cap sentit.

● L'entitat Encarregat és dubtosa ja que en un principi no s'ha detectat cap atribut diferent a Empleat, excepte el seu nivell de permisos, que es totalment diferent, però es te en compte per motius de permisos d'accés i de funcions de supervisió.


Il∙lustració : Diagrama estàtic de classes del model de negoci


5.2.2 Detall de les classes d'entitat mes representativesA continuació es mostren en detall les classes d'entitat mes representatives del sistema així com els seus atributs i mètodes principals. S'ometen les relacions que ja han quedat reflectides al diagrama estàtic de classes del model de negoci.


Il∙lustració :Detall de les classes d'entitat


5.2.3 Diagrama de classes d'ExcepcionsEl sistema de control d'errors esta basat en el sistema d'excepcions de Java o C++, donat que es vol aprofitar la potència i facilitat de control que aquesta filosofia permet.

Totes les classes hereten d'una classe interna anomenada Excepció que conté les parts estètiques i funcionals comunes a la resta de classes filles. Aquesta classe hereta al mateix temps d'una classe externa de Java anomenada java.lang.Exception.

5.2.4 Diagrama de classes d'Interfície d'UsuariLa interfície d'usuari és relativament senzilla en quant a la quantitat de pantalles a dissenyar, tenint en compte que el punt central de l'aplicació és la pantalla GetArticles.

Aquesta pantalla s'utilitzarà el 90% del temps i per tant ha de ser també la mes elaborada. La resta de classes frontera del sistema TPV2.0 son algunes pantalles de suport de la principal, els missatges i un senzill manteniment.


Il∙lustració : Diagrama de classes d'Excepcions


5.2.5

5.2.6 Diagrama de classes de PersistènciaLes classes de gestió de BD hereten d'una classe abstracta anomenada GestorDisc. Aquesta conté els mètodes i mecanismes per connectar a la base de dades i proporcionar a la resta de classes la capacitat de comunicació i creació d'instàncies a partir de consultes a les taules.

La classe GestorExcepcións és la responsable de desar o recuperar de la base de dades els registres corresponents als errors o excepcions que succeeixen al sistema. La seva funció és bàsicament de registre d'incidències, ja que la extracció d'aquestes per motius de rendiment o manteniment queda forma del abast d'aquest projecte.

La classe GestorTiquet és realment una classe contenidora de mètodes diversos que s'encarreguen de la gestió de les instàncies de la classe Tiquet, de la classe LiniaDeTiquet,


Il∙lustració : Diagrama de classes d'Interfície d'Usuari


de la classe ControlEfectiu i de la classe MovimentEfectiu.

La resta de classes del diagrama son auto explicatives.

5.2.6.1 Gestió del nivell de persistència

Els gestors de disc son també els responsables de garantir que les dades que s'estan proporcionant són les mes òptimes en cada moment en funció de la seva disponibilitat.

La classe gestorTiquet sempre proporciona dades crítiques o d'alta disponibilitat ubicades localment. La resta de classes gestores han de tenir implementats mètodes que gestionin la millor opció en funció de l'estat de les comunicacions i de la disponibilitat de les dades.

Per exemple, si la classe GetArticles demana les dades d'un article i aquestes estan


Il∙lustració : Diagrama de classes de Persistència


disponibles en el nivell remot (consultar l'apartat Persistència de les dades a la fase d'anàlisi) la classe gestora les proporcionarà d'aquesta font i les emmagatzemarà a la base de dades local en forma de memòria cau per posteriors consultes, si les condicions de disponibilitat varien.

Al cas contrari, si la classe GetArticles demana les dades d'un article i en aquell instant es dona un tall de comunicacions a la xarxa local i les dades dels articles no estan disponibles, la pròpia classe gestorTiquet ha de detectar aquesta anomalia i proporcionar de manera transparent les dades al la classe GetArticles.

5.3 Diagrames dinàmics

5.3.1 Diagrama de seqüència Alta d'Usuari


Il∙lustració : Diagrama de seqüència Alta d'Usuari


5.3.2 Diagrama de seqüència Iniciar Tiquet

5.3.3 Diagrama de seqüència Cobrar Article per Codi



5.3.4

5.3.5 Diagrama de seqüència Informar Efectiu


Il∙lustració : Diagrama de seqüència Cobrar Article per Codi



Il∙lustració : Diagrama de seqüència Informar Efectiu


5.3.6 Diagrama de seqüència Totalitzar Tiquet

5.3.7 Diagrama de col∙laboració Tancament de Caixa


Il∙lustració : Diagrama de seqüència Totalitzar Tiquet


5.3.8 Diagrama de col∙laboració Arqueig de Caixa


Il∙lustració : Diagrama de col∙laboració Tancament de Caixa


5.3.9 Diagrama de seqüència Pagament de CaixaEn aquesta seqüència no es gestiona cap tipus d'error ja que les dades informades al formulari PagamentDeCaixa son sempre validades abans de prémer el botó d'acceptar i son condició imprescindible per a poder continuar amb la seqüència.


Il∙lustració : Diagrama de col∙laboració Arqueig de Caixa



Il∙lustració : Diagrama de seqüència Pagament de Caixa


5.3.10 Diagrama de seqüència Devolució d'Articles

5.3.11

5.3.12 Diagrama de seqüència Entrada d'Usuari


Il∙lustració : Diagrama de seqüència Devolució d'Articles


5.4 Disseny de la interfície gràfica d'usuari (GUI)A continuació es mostren els prototipus d'algunes de les pantalles que formen part de la interfície gràfica d'usuari de l'aplicació.

Per motius de temps i d'espai al document s'han recopilat solament algunes de les més representatives i s'han omès les que no aporten informació específica o representativa de l'aplicació. Per exemple la pantalla d'enregistrarse al sistema (login) o bé les de manteniment d'usuaris.


Il∙lustració : Diagrama de seqüència Entrada d'Usuari


5.4.1 Pantalla Informar d'efectiu


Il∙lustració : Pantalla Informar d'efectiu


5.4.2 Pantalla Pagament de caixa


Il∙lustració : Pantalla Pagament de caixa


5.4.3 Pantalla Devolució d'articles


Il∙lustració : Pantalla Devolució d'articles


5.4.4 Pantalla Cobrar articles


Il∙lustració : Pantalla Cobrar articles


5.4.5 Pantalla Tancar transacció efectiu


Il∙lustració : Pantalla tancar transacció efectiu


5.4.6 Pantalla Tancar transacció TEF

6 Glossari de termes de negociBalanç de caixa: Extracte d'anotacions de moviments de caixa, a través del qual hom pot fer constar, comprovar o demostrar l'exactitud en la relació entre les operacions i la quantitat d'efectiu existent a la caixa.Caixa: denominació genèrica que se li dóna a una ubicació física on s'efectua el cobrament


Il∙lustració : Pantalla Tancar transacció TEF


al client. Normalment està composat per un moblecaixa, un TPV o bé a una caixa enregistradora i tots els perifèrics i estris necessaris.Caixa central: Maquinari i programari ubicat dintre de la pròpia botiga que fa la funció de concentrador, de control, distribució i supervisió dels processos dels TPV i de gestió de les reclamacións.Caixa enregistradora: Dispositiu format únicament per maquinari, amb una programació fixada de forma electrònica i que té la funció de valorar els productes, rebre un pagament per ells i emetre un comprovant de compra. Les seves capacitats de comunicació i procès són limitades.Caixer/a: persona encarregada del cobrament per caixa dels diferents productes.Canvi: Dintre de l'argot de botiga, és l'efectiu que hi ha en un moment donat al calaix portamonedes.Cartelleria: Panells o plafons publicitaris a l'interior de la botiga que fan referència a preus, ofertes, promocions, etc...Catàleg: estructura de dades on hi ha els articles disponibles per a la venda i els seus corresponents preus, entre d'altres.Client anònim: client que no esta identificat al moment de fer el cobrament i que no pertany a la base de dades de clients de Kobrabo.Client identificat: client que al moment de fer el pagament s'identifica amb una tarja de client o similar. Llavors se li poden aplicar descomptes, avantatges personalitzats, etc... També se li pot emetre un tiquet al seu nom que, a més, permet fer un tractament estadístic de les seves compres.Codi EAN: Sistema d'identificació per codis de barres format per una sèrie de dígits i orientat al processament per medis electromecànics.Codi PLU: Price LookUp code o codis d'identificació de preus és un sistema d'identificació d'articles basat en codis numèrics, implantat al 1990 i regulat per la International Federation for Produce Standards als EUA que facilita el control i venda d'aliments al sector de la distribuició, sobretotControl d'efectiu: control de caixa.Control de caixa: A petició del supervisor de zona o de l'encarregat de botiga, el caixer ha de comptar l'efectiu que té en aquell moment a la caixa i informar al sistema.Efectiu de caixa: diners que actualment estan físicament a la caixa o que pertanyen a ella. Per exemple, la caixa pot haver recaptat 1300 euros durant el matí però per motius de seguretat, 300 estan dintre del calaix portamonedes i els 1000 restants estan a la caixa forta de la botiga.



Encarregat: Persona responsable de la botiga, del cobrament, del tancament i obertura i de les instal∙lacions en general.Expansió tipus “taca d'oli”: Creixement geogràfic expansiu, aproximadament circular, en base a un punt inicial central.Lineal: agrupació i exposició de productes a la venda en una ubicació determinada.Línia de venda: agrupació i exposició de productes a la venda per una categoria determinada (llar, refrigerats, neteja, fruiteria, etc..).Obertura de dia: Inici de jornada comptable d'un TPV.Obrador: lloc on es prepara el gènere per presentar a la botiga quan aquest necessita d'alguna manipulació prèvia.Operador de Caixa: Caixer/a.Promocions m x n: Promocions consistents en què per la compra de m articles, el client unicament paga n. Per exemple, a una promoció de 3x2 el client selecciona tres productes iguals i el TPV aplica un descompte del 100% a un d'ells.PLU: Price LookUp code o codis d'identificació de preus és un sistema d'identificació d'articles basat en codis numèrics, implantat al 1990 i regulat per la International Federation for Produce Standards als EUA que facilita el control i venda d'aliments al sector de la distribuició, sobretot d'aliments orgànics.Quadrar caixa: Arran d'un o varis controls de caixa, comparar els moviments de diners reflectits a la caixa amb l'efectiu existent en aquell moment.Reposador: persona que reposa gènere als lineals, descarrega camions, controla estocs al magatzem, manté la neteja bàsica dels obradors i que eventualment pot fer tasques de caixer.Segon responsable: Persona que pot fer el paper de responsable en cas de que sigui necessari.Supervisor de zona: persona que supervisa les accions de l'encarregat.Tancament de dia: Fi de la jornada comptable d'un TPV.Targeta de client: identificació en forma de tarjeta, pin o qualsevol altre medi, que identifica unívocament a un client envers el sistema de cobrament per tal d'aplicarli un tractament diferenciat i també recollir dades estadístiques de la seva compra.TEF: Sigles de Transferència Electrònica de Fons. Sistema que permet gestionar un cobrament al client, mitjançant el TPV, entre l'entitat bancària emissora i receptora i amb total seguretat. Tiquet: comprovant de pagament de caixa en format paper amb la mateixa validesa jurídica i fiscal que una factura.



Totalitzar el compte: fet l'acció de sumar l'import dels productes que conté la compra d'un client, amb totes les dades disponibles fins al moment (descomptes, promocions, etc...), i emetre un import total.TPV: Terminal Punt de Venda. Dispositiu electrònic instal∙lat a un punt de venda, format per maquinari i programari, que té la funció de valorar els productes, enregistrarlos, rebre un pagament per ells i emetre un comprovant de compra. Aquest dispositiu té la capacitat de treballar connectat en xarxa amb altres TPV's i de executar funcions avançades. Normalment la plataforma de maquinari és d'arquitectura PC o similar.TPV màster o concentrador: TPV o estació de treball que fa les funcions de concentrar les dades de vendes, consum, moviments, etc... de la jornada i de supervisió dels processos.

7 Bibliografia

Caballé, S.; Xhafa, F. (2008). Aplicaciones distribuidas en java con tecnología RMI. Madrid: Delta Publicaciones Universitarias.

Craig Larman. (2003). UML y Patrones. Madrid: Prentice Hall.

Wikipedia. Price LookUp code. [en línia]. http://en.wikipedia.org/wiki/Price_LookUp_codes [21/11/08].

LuAuF. Configurar replicación en MySQL. [en línia]. http://luauf.com/2008/06/09/configurarreplicacionenmysql/ [02/11/08].

Jorgelig Blog. Algunos links para Replicacion con Mysql. [en línia]. http://jorgelig.la100rra.com.mx/2008/07/08/algunoslinksparareplicacionconmysql/ [02/11/08].

Monografias.com. El Mercadeo al detalle y las principales instituciones detallistas que intervienen en la distribución. [en linia]. http://www.monografias.com/trabajos18/distribucionlocalizacion/distribucionlocalizacion.shtml#intro [30/10/08].

Cuesta Valiño, P. Estrategias de crecimiento de las empresas de distribución comercial. [en línia]. http://www.eumed.net/tesis/2006/pcv/1p.htm [30/10/08].

Ecologistas en accion. Los mitos de los supermercados. [en línia].



http://www.ecologistasenaccion.org/IMG/pdf__Mitos.pdf [01/11/08].

Diccionario Alkona de economía, entrada 1020. Código EAN. [en línia]. http://www.diclib.com/cgibin/d1.cgi?l=es&base=alkonaeconomia&page=showid&id=1020 [02/11/08].

El prisma. Transferencia Electrónica de Fondos – TEF. [en línia]. http://www.elprisma.com/apuntes/economia/transferenciaelectronicadefondos/default2.asp [2/11/08].

El Economista. Pérdida desconocida costará 2.645 millones a la distribución española en 2007. [en línia]. http://www.eleconomista.es/empresasfinanzas/noticias/313251/11/07/Perdidadesconocidacostara2645millonesaladistribucionespanolaen2007.html [5/11/08]

Wikipedia. Payment Card Industry Data Security Standard. [en línia]. http://en.wikipedia.org/wiki/PCI_DSS [21/11/08].

Fifth Third Bank. Norma de Seguridad de Datos para la Aplicación de Pagos. [en línia]. https://espanol.53.com/enes/wps/portal/sv?New_WCM_Context=/wps/wcm/connect/FifthThirdSite/Small+Business/Merchant+Services/Payment+Card+Data+Security+Requirements/PADSS/ [5/11/08].

Microsoft. Windows Embedded for Point of Service Innovation Lane. [en línia]. http://www.microsoft.com/windowsembedded/enus/devices/realworld/lane.mspx [20/12/08].Sergio Hernando. Diez distribuciones Linux ligeras para uso en equipos poco potentes y/o obsoletos. [en línia]. http://www.sahw.com/wp/archivos/2006/07/20/diezdistribucioneslinuxligerasparausoenequipospocopotentesyoobsoletos/ [20/12/08]

8 AnnexEn aquest annex es detallen alguns temes d'interès relacionats amb el treball que aporten dades útils i/o complementàries però que no tenen cabuda directa en cap capítol del mateix.

8.1 Possibles ampliacions futures de TPV2.0Durant el desenvolupament del projecte s'han anat incorporant tota una sèrie d'idees o millores que per la seva tardana aparició no han pogut ser incorporades al projecte principal



però que tenen interès futur. Per aquest motiu, s'ha cregut convenient esmentarles sense entrar en profunditat deixant constància de les mateixes i deixant la porta oberta a estudiar la seva viabilitat futura.

8.1.1 Sistema de promocionsUna de les ampliacions futures de TPV2.0 pot ser l'evolució del sistema de promocions actual cap a un sistema complex on es puguin gestionar les diferents combinacions de promocions provinents dels diferents departaments de Kobrabo.Cada un d'aquests departaments pot ser independent en quant a la creació d'aquestes promocions (Màrqueting, Comercial, Producte, Imatge, etc...) i pot no estar necessàriament coordinat amb la resta. Per tant, el sistema de promocions de Central ha de captar les dades del sistema de Planificació de Recursos Empresarials (ERP) o bé d'altres fonts diverses i heterogènies i formatarles adequadament per als sistemes de botiga.Aquests darrers, per la seva banda, han de ser capaços d'entendre i interpretar la complexitat d'aquestes promocions i aplicarles en temps real al TPV i sense generar cap conflicte.

8.1.2 Control de presènciaUna altra ampliació que pot ser implementada a TPV2.0 en un futur és el control de presència del personal a les botigues. Aprofitant que els TPV són punts de connexió estables i permanentment operatius, poden actuar com a “rellotges de fitxar” del personal humà a les botigues. Més enllà de la seva funcionalitat actual d'identificar als usuaris únicament quan es validen a l'aplicació per a cobrar o fer qualsevol altre operació, aquesta nova funcionalitat permetria amb mètodes biomètrics validar les entrades i sortides dels empleats respecte als seus torns de treball.

8.2 Quantificació del volum de tràficUn dels temes d'aquest treball que s'ha quedat al tinter és un estudi de la quantificació precisa del volum de dades que han de circular pels diferents canals de comunicació. Com a canals de comunicació s'entenen la infraestructura de xarxa local o LAN i la infraestructura de xarxa remota o WAN. Aquest estudi és necessari si es volen automatitzar les comunicacions de forma segura.

Per exemple, un augment considerable del número de botigues podria provocar que el temps de preparació a central de les dades corresponents als catàlegs de preus,



promocions i altres dades de rotació diària es dilatés fins al punt que no fos possible enviar aquestes a les botigues abans de la seva obertura al públic.

Una bona estimació de la càrrega de xarxa en funció del creixement futur ajudaria a prevenir aquest tipus de desastres.

8.3 Recomanacions d'infraestructuraPer a portar a terme la materialització del projecte mitjançant les fases de programació i posterior implantació de l'eina, hi ha una sèrie de recomanacions sobre les quals basar aquestes. De totes maneres, tenint en compte que aquest treball es basa en les fases primerenques d'una eina, tant la infraestructura com la implementació d'aquesta poden ser decidides posteriorment amb total llibertat.

8.3.1 MaquinariPer a implementar el maquinari existeixen una sèrie de dispositius al mercat adaptats a aquest tipus de negoci. De totes maneres, es fa molt difícil recomanar algun producte en concret ja que hi ha gran varietat al mercat. A continuació s'enumeren alguns dels perifèrics més representatius.

● Terminal. Plataforma amb arquitectura PC o compatible, amb el seu maquinari preparat per suportar múltiples perifèrics i amb ergonomia similar a una caixa enregistradora.

● Teclat programable. Teclat de 40, 84, 105 o 112 tecles amb connexió estàndard i amb la capacitat de programar internament el codi retornat per cada tecla. Esta adaptat per a suportar impactes forts, vessat de líquids i entorns agressius.

● Calaix portamonedes. Dispositiu amb forma de calaix blindat que conté monedes i bitllets per a facilitar les transaccions de venda a una botiga o establiment. Es pot obrir automàticament i detectar el seu estat (obert o tancat).

● Monitor. Pantalla de mida reduïda (9, 12, 13 i 15 polzades) adaptada a entorns agressius, amb gran lluminositat, capacitat tàctil i ancoratges específics.

● Escànner. Lector de codi de barres (EAN) basat en làser. Pot ser de mà, fix i de diferents potències depenent del tipus d'entorn i productes a enregistrar.

● Visor. Maquinari annexat al TPV consistent en un pal que suporta un visor o pantalla de dimensions reduïdes. Aquesta pantalla, orientada al client, l'informa de l'article en curs, el preu o qualsevol altre informació adient. Esta dissenyat per a veure els dígits



a distàncies d'entre 50 centímetres i 2 metres.● Impressora de tiquets. Impressora que emet tiquets. La tecnologia pot ser matricial,

de tinta o tèrmica. Normalment son monocrom i d'unes 40 columnes. Està adaptada a un espai de treball reduït i posseïx una gran velocitat d'impressió per a evitar esperes innecessàries.

8.3.2 Sistema operatiu i entornExisteixen una sèrie de sistemes operatius adaptats i orientats específicament a dispositius com el TPV. El més comercial i conegut de tots ells pertany a la familia Embedded de la casa Microsoft, concretament és el sistema Windows Embedded for Point of Service Innovation Lane.Aquest sistema operatiu propietari i sota llicència és una versió de Windows reduïda i adaptada a clients de xarxa lleugers i entorns de treball amb poca memòria, poc processador o poca capacitat d'emmagatzematge respecte a un entorn de treball convencional. Aquest, però, compta amb unes característiques de compatibilitat amb maquinari que li permeten adaptarse a impressores de tiquets, lectors de codi de barres i un gran ventall de dispositius similars. Els avantatges d'aquest sistema operatiu són el suport tècnic que té al darrere i la garantia d'una companyia reconeguda a nivell mundial com és Microsoft.Per una altra banda, tot seguint la línia que l'autor vol defensar envers la idoneïtat del programari de lliure distribució i codi obert, es posa de manifest l'opció d'instal∙lar com a plataforma una de les moltes distribucions de que disposa el sistema operatiu GNU Linux. Hi han desenes d'elles, cadascuna amb les seves característiques específiques. Algunes d'elles molt lleugeres com Vector, Zen Walk, Xubuntu, DeLi Linux, Slax, Damn Small, Feather, Puppy, muLinux o Austrum. La versatilitat i facilitat de que disposa Linux per a ser modificat i adaptat a l'entorn són un bon punt de partida per a crear una plataforma de TPV estable i fiable.Un dels punt negatius, però, és la manca de suport oficial i per tant es fa imprescindible tenir disponible un equip d'experts en aquest sistema per tal de fer l'adaptació necessària. De totes menes, donat que la plataforma de maquinari a Kobrabo és pretén que sigui estàndard, un cop creada la primera “imatge” estable del sistema operatiu aquesta pot ser instal∙lada a tots els terminals sense adaptacions profundes.Finalment, per al tractament de les dades als TPV es recomana MySql. Aquest SGBD (sistema gestor de base de dades) de lliure distribució és lleuger, eficient i poc exigent en quant a recursos. Tenint en compte que la càrrega de dades local no és quantitativament



important, és perfectament assolible la gestió amb aquest SGBD.

8.3.3 Llenguatge d'implementacióPer a la fase d'implementació del projecte es pot utilitzar qualsevol llenguatge Orientat a Objectes tot i que s'ha d'observar un característica important i inherents als sistemes TPV.Aquesta característica és la necessitat de rapidesa de resposta que es requereix envers el maquinari i els perifèrics. Aquesta rapidesa de resposta és imprescindible per a adaptarse al ràpid ritme de gestió dels operadors de caixa i a les entrades de dades simultànies. En cas d'una aplicació feta amb un llenguatge de programació interpretat (ASP, JavaScript, PHP, VBScript, etc...) s'ha de tenir molt en compte l'augment de capes d'abstracció entre el codi i el maquinari i el conseqüent alentiment de resposta amb màquines lentes.

8.4 Llista del programari utilitzatFinalment es vol fer esment d'una fita experimental i personal que l'autor ha volgut portar a terme. Aquesta fita ha sigut intentar elaborar tot el treball utilitzant el màxim possible de programari lliure i de codi obert. Això no ha sigut possible al cent per cent, per condicionants de temps i recursos, però sí que s'ha aconseguit un resultat satisfactori molt proper al desitjat. A continuació es llisten les diferents eines utilitzades i les seves característiques principals.

● Entorn de treball: Ubuntu 7.04 (feisty). Sistema operatiu basat en GNU Linux de codi obert i lliure distribució.

● Diagrames UML: MagicDraw UML 12.0 (versió d'avaluació). Magnífic programari propietari, sota llicència de la casa No Magic, Inc., per a analitzar i dissenyar sistemes Orientats a Objectes i bases de dades.

● Maquetació, tractament de text i exportació a PDF: OpenOffice Writer 2.2.0. Programari de lliure distribució i codi obert pertanyent al paquet OpenOffice i orientat a la creació i tractament de textos.

● Presentació: Open Office Presentation 2.2.0. Programari de lliure distribució i codi obert pertanyent al paquet OpenOffice i orientat a la creació i tractament de presentacions.

● Diagrames E/R: Dia 0.96.1. Programari de lliure distribució i codi obert orientat a la creació de diagrames estructurats.

● Prototips d'interfície gràfica d'usuari: Eclipse 3.2 amb l'extensió Visual Editor SDK



1.2.0. Entorn de desenvolupament de lliure distribució i codi obert per a implementar interfícies gràfiques en codi Java.

● Diagrames Gannt i planificació: Planner 0.14.2. Programari de lliure distribució i codi obert orientat a la planificació i gestió de projectes.

● Tractament d'imatges: The Gimp 2.2.13. Programari de lliure distribució i codi obert orientat al tractament i creació de gràfics i imatges.


Documents

Especificacions, anàlisi i disseny d'un programari de ...openaccess.uoc.edu/webapps/o2/bitstream/10609/75685/6... · dissenya un sistema anomenat TPV2.0 per a gestionar terminals