aplicatiu de gestió d’incidències en comerç...

Aplicatiu de gestió d’incidències en

Comerç Electrònic

AUTOR: Pere Ferrer Casaoliva . DIRECTOR: Enric Vidal Idiarte .

DATA: Setembre / 2004.

Índex

ÍNDEX

1. Memòria Descriptiva 2. Memòria de Càlcul

3. Plànols 4. Pressupost

5. Plec de Condicions 6. Annexes

Índex 1

Memòria Descriptiva

1.Memòria Descriptiva.

Índex Índex.................................................................................................................. 1 1. Memòria Descriptiva ................................................................................ 2

1.1. Objectius del Projecte............................................................................................ 2 1.2. Titular .................................................................................................................... 2 1.3. Privacitat de l’Informació...................................................................................... 2 1.4. Descripció de l’Empresa........................................................................................ 3

1.4.1. Introducció ........................................................................................................ 3 1.4.2. Getronics Espanya............................................................................................. 4 1.4.3. Solucions i Serveis de Getronics Iberia............................................................. 5 1.4.4. Solucions Especialitzades.................................................................................. 8 1.4.5. Estructura ........................................................................................................ 15 1.4.6. Localització ..................................................................................................... 16

1.5. Situació Dins de l’Empresa ................................................................................. 17 1.6. Comerç Electrònic ............................................................................................... 19

1.6.1. Mitjans Pagament Electrònics ........................................................................ 19 1.6.1.1. Targeta de Crèdit /Dèbit: ......................................................................... 19 1.6.1.2. Targeta Moneder...................................................................................... 33 1.6.1.3. Pagament amb Mòbil............................................................................... 35 1.6.1.4. Targeta Intel·ligent .................................................................................. 37 1.6.1.5. Targetes de Radiofreqüència (Teletac).................................................... 40

1.6.2. Mitjans Cobrament Electrònics....................................................................... 44 1.6.2.1. Bacaladera ............................................................................................... 44 1.6.2.2. Terminal Punt de Venda On-Line ........................................................... 44 1.6.2.3. TV Interactiva:......................................................................................... 46 1.6.2.4. Terminal Punt de Venda Off-Line........................................................... 48 1.6.2.5. Caixers Automàtics ................................................................................. 48 1.6.2.6. TPV Virtual ............................................................................................. 49

1.6.3. Comunicacions ................................................................................................ 51 1.6.3.1. ADSL:...................................................................................................... 51 1.6.3.2. Fibra Òptica: ............................................................................................ 53

Memòria Descriptiva 1


1. Memòria Descriptiva

1.1. Objectius del Projecte

El projecte és una aplicació de software en entorn Host destinada a la millora del control i rendiment dels diferents mitjans de pagament que s’utilitzen actualment. També es pretén donar una visió general de la vessant electrònica que formen els mitjans de pagament en la actualitat i en el futur.

1.2. Titular

El titulars del projecte és una important entitat financera del país. És un dels clients més importants de l’empresa de serveis informàtics Getronics Iberia. L’oficina de Tarragona es troba situada a:

Getronics Iberia S.A. Av. Roma nº 18 43004 – TARRAGONA

1.3. Privacitat de l’Informació

Dins de Getronics existeix un compromís contractual amb el client per preservar la privacitat de les dades d’aquests. Per aquesta raó en aquest document no poden aparèixer dades concretes del client (Nom, Informació del client, etc.) ni dades concretes sobre el disseny o la implementació del projecte (Dades d’anàlisis, Codi font, Bolcats de pantalles, etc.). La informació aquí continguda només pretén ser una breu aproximació al problema i donar una lleugera idea del tipus de feina realitzada.



1.4. Descripció de l’Empresa

1.4.1. Introducció

Getronics és una empresa multinacional d’origen Holandès, proveïdora de solucions i serveis TIC (Tecnologia de l’Informació i les Comunicacions), amb una facturació de 3.600 milions d’euros durant l’any 2003. Compte amb una plantilla de aproximadament 23.000 empleats distribuïts per més de 30 països. Amb més de 100 anys d’antiguitat, Getronics està situada entre els cinc primes lloc del ranking mundial de proveïdors TIC.

La seu central es troba a Amsterdam, però també disposa de seus regionals a Bòston, Londres, Washington i Singapur. Getronics aspira a ser el proveïdor líder de solucions i serveis TIC en el món del comerç electrònic. El seu objectiu és el de subministrar solucions avançades i serveis TIC, independentment del fabricant per tal de permetre als seus clients, tant a nivell mundial com local, aconseguir i inclòs superà els seus objectius de negoci.

Una de les principals virtuts de Getronics resideix en la seva presencia local. El passat recent de Getronics com “holding” de empreses independents, l’ha portat a tenir una presencia local i personalitzada.

A més de les seves oficines, Getronics compta amb una xarxa de “Getronics Vertifed Service Partners”, proveïdors autoritzats de servis per donar cobertura als nostres clients allí on ells ho necessiten. Gràcies a això, Partners Getronics pot proveir solucions i serveis d’infrastructures TIC a més de 100 països. Per lo que indirectament s’amplia la presencia mundial de la multinacional.

Getronics esta present, de manera directe als següents països: Alemanya, Austràlia, Àustria, Bèlgica, Brasil, Canadà, Colòmbia, Xile, Xina (Inclòs Hong Kong), Emirats Àrabs, Eslovàquia, Eslovènia, Espanya, Estats Units, Holanda, Hongria, Irlanda, Israel, Itàlia, Japó, Luxemburg, Malàcia, Mèxic, Polònia, Portugal, Puerto Rico, Regne Unit, República Txeca, Singapur, Suïssa, etc.



Figura 1. Presencia Mundial de Getronics.

Getronics compta amb dos òrgans de direcció principals:

• Consell de direcció: Format pel president (Axel Bückert) i vice-president (Klass Wagenaar), els quals van incorporar-se a l’empresa l’any 2003.

• Comitè de direcció: Format pel president del consell de direcció, el

vice-president del consell de direcció, el vice-president de comunicacions corporatives, el vice-president de recursos humans, el vice-president de finances i els directors generals de les subsidiàries.

1.4.2. Getronics Espanya

Getronics entra a Espanya al 1980 oferint serveis de infrastructures tecnològiques a través de l’empresa DIODE.

Al 1998 adquireix GrupoCP, una de les majors companyies espanyoles en el camp de la consultoria i les tecnologies de l’informació fundada al 1966, donant lloc a una nova companyia que passa a dir-se Getronics GrupoCP. D’aquesta manera Getronics s’introdueix en el mercat de desenvolupament de solucions de negoci i consultoria en el mercat Espanyol, Portuguès i Llatinoamericà.

Més tard, al 1999, Getronics adquireix Wang Global, la qual havia adquirit anteriorment OLSY, la filial de serveis i solucions de Olivetti. Wang Global Espanya passa a ser Getronics Espanya Solutions i així Getronics es converteix en un proveïdor líder de solucions d’infrastructures a Espanya.



Durant l’any 2000 el grup Getronics decideix unificar totes les seves empreses al territori Espanyol sota el mateix nom. Comença un procés de integració entre Getronics GrupoCP i Getronics Espanya Solutions per agrupar totes les activitats que desenvolupen les dos companyies sota una sola direcció i així millorà la seva oferta de solucions i serveis. Al Gener del 2001 neix Getronics Iberia, com a resultat de la total integració de Getronics GrupoCP i Getronics Espanya Solutions, convertint-se en una marca global, una companyia global i la oferta més completa del mercat amb 35 anys de provada experiència. Al mateix temps que es realitza aquesta integració, Getronics ven DIODE als seus propis directius.

Getronics Iberia, per tant, forma la representació de Getronics a la península d’Iberia, compte amb 19 oficines a Espanya i una a Portugal, cobrint la totalitat del territori nacional, una característica essencial per oferí els seus serveis de gestió i manteniment de xarxes i equipaments TIC.

1.4.3. Solucions i Serveis de Getronics Iberia

En totes les seves solucions i serveis, Getronics ofereix a les companyies una visió integrada que uneix solucions de negoci i e-Business amb una amplia experiència en integració i gestió de tecnologies i xarxes. Les capacitats es divideixen en dos àrees complementaries, donant lloc a una oferta única al mercat per l’amplitud de la seva cobertura i la profunditat de la seva especialització.

• Solucions de negocis i consultaria. • Solucions d’infrastructures TIC.

Oferta Integrada

Les diferents activitats que Getronics realitza es troben totalment integrades unes amb les altres, ja que el desenvolupament de potents solucions de negoci no pot realitzar d’una manera independent al disseny de les infrastructures que han de suportar.

Getronics, com proveïdor integral de solucions, assumeix amb els seus clients un compromís que poques companyies poden compartir, el desenvolupament de solucions completes.



S’identifiquen les necessitats del client i es valoren els recursos existents per una possible reutilització. Es dissenyen solucions de hardware/software a mida, es posen en marxa independentment del lloc (incloent desplegaments massius) i s’ofereix el manteniment del projecte, en els formats temporals desitjats pel client.

Solucions de Negoci i Consultoria

Getronics proporciona serveis de consultoria, disseny, integració i gestió per tal d’optimitzar processos i arribar als objectius de negoci dels seus clients. Les solucions de negoci de Getronics es troben agrupades en dos programes globals:

• CustomerPlace, que proporciona les eines necessàries per establir una relació personalitzada amb cada un dels clients.

• KnowledgePlace, que proporciona les eines necessàries per la gestió dels

coneixements i dels fluxos de treball, per ajudar a als clients a agilitzar processos i utilitzar la informació d’una manera més efectiva.

Solucions d’Infraestructura TIC

Getronics ofereix serveis de consultoria, disseny, integració, subministrament i gestió avançada de xarxes. Aquesta oferta de Getronics s’integra dins del programa Global NetworkPlace.

A continuació, detallem els serveis més importants que ofereix Getronics Iberia:

Consultoria de Gestió:

Organització. Gestió de Canvi. Gestió de Negoci. Gestió Comercial i de Marketing de Qualitat.



Solucions Especialitzades:

Banca: Mitjans de Pagament, Control de Gestió, Riscos. Assegurances: Plataforma Integral. Indústria, Comerç i Serveis: Gestió, Operacions, Economia Financera i

Pressupostaria. Tecnologies Avançades: Datawarehouse.

Consultoria Tecnològica:

Diagnòstics i Auditories. Seguretat Informàtica. Plans de Sistemes. Organització Informàtica.

Sistemes Informàtics:

Direcció de Projectes. Desenvolupaments d’Aplicacions. Conversió de Sistemes. Implantació de Sistemes.

Serveis Informàtics:

Prestacions Professionals. Manteniment d’Aplicacions. Software Factory. Teleworking. Gestió de Xarxes.

Serveis de Suport:

Formació Informàtica. RR.HH. Implantació de Productes.



1.4.4. Solucions Especialitzades

Getronics Iberia, a més a més ofereix una sèrie de solucions amb les que està especialitzada, amb l’objectiu de produir una sèrie de serveis amb una contrastable millora de la qualitat i una reducció de despeses de desenvolupament. Getronics es troba dividida en diferents sectors.

Sector Financer

Getronics és líder destacat a l’oferta de solucions i serveis pel Sector Financer, entre els clients es troben els principals Bancs i Caixes del país. Ofereix una cobertura integral en tots els aspectes relacionats amb els sistemes d’informació i comunicació de les entitats financeres.

Les entitats financeres són pioneres en l’implantació de models de negoci basats en la tecnologia (Caixers d’Autoservei, Terminals Punt de Venda, Banca Electrònica, Banca Mòbil, etc.). Aquestes noves tecnologies ofereixen a les entitats financeres l’oportunitat d’estalviar despeses, al mateix temps que augmenten la rendibilitat de les seves operacions, incrementant el número de clients i facilitant la posada en marxa de nous canals més eficients i rentables.

Dins dels sector financer es té una amplia experiència, oferint els següents serveis:

• Mitjans de Pagament. • Banca Electrònica. • Centre d’Atenció a Clients.

• DataWarehouse.

• Gestió de Risc.

• Sistemes de Gestió d’Informació.

• Assegurances.

• Sistema de Gestió Integral.

• Aplicacions Financeres Integrades.



Entre els clients de Getronics podem destacar:

Bancs:

Bancaja. Banc Atlàntic. Banc Guipúscoa. Banc Santander Portugal. Banesto. Bankinter. Barclays Bank. BBVA. SCH.

Caixes d’Estalvi:

BBK. Caixa Espanya. Caixa General de Granada. Caixa Madrid. Caixa Múrcia. Caixamar. CECA. Ibercaja. La Caixa.

Altres Entitats Financeres:

Banc March. Banc d’Espanya. Fibanc. Fimestic. Hispamer. Iberia Cards. Interbank. SERMEPA.



Sector Assegurador

Getronics Iberia ofereix solucions de negoci pel sector assegurador des de fa 25 anys, això la situa com a proveïdor líder en aquest mercat.

Durant els darrers anys està creixent la participació de les companyies d’assegurances dins de les “Noves Tecnologies”. Es necessari ampliar el negoci a nous canals de comercialització, com són internet, les telecomunicacions o les solucions mòbils. Les empreses d’assegurances s’han adonat que els canals tradicionals s’han anat transformant i és necessària una modernització.

Aquestes entitats mostren un especial interès en millorà la seva atenció al client i la seva qualitat de servei. Per altra part, també la pressió sobre els marges de beneficis fan que el control de rendibilitat dels clients sigui fonamental, pel que és imprescindible tenir una correcta informació sobre la rendibilitat de les diferents línies de productes i segments del client.

Entre les empreses que s’hi ofereix servei podem trobar:

Companyies d’Assegurances

Alianza Espanyola. Azur Assegurances. Caifor. Caser. Crèdit Andorrà. General AIE. Joao Mata Ltda. Mapfre. Musini. Ocaso. Plus Ultra. Pool de Riscos Mediambientals. Previsió Sanitària Nacional. Sanitas. Assegurances Lagún Aro. Assegurances RGA. Sud Amèrica Mans. Victoria Meridional. Winterthur. Zurich.



Companyies de BancAssegurances

Banc Atlàntic. Banc del Comerç. Banesto. Bankinter. Barclays Vida i Pensions. Biharco. Caixa Galícia. Citibank. Pastor Vida. Santander Central Hispano.

Entitats del sector

Audatex. Consorci de Compensació d’Assegurances. ICEA.

Indústria, Comerç i Serveis

Getronics aporta una amplia varietat de serveis i solucions tecnològiques, dirigits a una continua evolució cap a models de gestió i serveis avançats. Entre els serveis que s’ofereixen al sector industrial tenim:

• Implantació de Serveis per Sistemes Integradors. • E-Commerce.

• Gestió Integral de Sistemes.

• Suport de l’Explotació.

• Gestió de Recursos Humans.

• Implantació de Sistemes de Qualitat.

• Software Factory.

• Implantació de Sistemes a Mida.



A continuació detallem els clients més importants de Getronics en els següents sector:

Indústria i Distribució

Affinity Petcare. Aigües de Barcelona. Anaya. Sucrera Ebro. Bodegues Torres. Carrefour. Ciba Visior. Correus. Damm. Danone. El Corte Inglés. Endesa. FACSA. FEVE. Heineken. Iberdrola. KAO Corporation. Mecalux. ONCE. Renfe.

Companyies Petrolíferes i d’Automoció

BP. Cepsa. Fiat. Ford. Many Cars. Michelín. Renault. Repsol YPF.



Administració Pública

Getronics aporta una amplia gamma de serveis i solucions tecnològiques per les Administracions Públiques, recolzant la seva continua evolució cap a models de gestió i serveis públics avançats.

Les noves tecnologies s’han introduït a la societat adquirint un paper predominant, s’han creat nous canals d’interacció i relació humana. Això afecta a les Administracions Públiques per poder oferir un servei de qualitat als ciutadans. Tenen la necessitat de modernitzar els seus procediments de funcionament, models de atenció al ciutadà i infrastructures tecnològiques.

Des del sector de l’Administració Pública s’ofereix els següents serveis:

• Sistemes de Gestió d’Informació. • Implantació de Sistemes d’Informació Hospitalàries. • Sistemes d’Informació pels Serveis Centrals del Sistema Nacional de

Salut. • Metodologies i Eines pels Processos de Reenginyeria.

Getronics té una forta experiència en l’administració pública, per lo que compte amb importants centres del sector:

Administració Central

Agencia Espanyola dels Medicaments. Exercit de l’Aire. Guàrdia Civil. Ministeri de Justícia. Ministeri de Medi Ambient. Ministeri de Sanitat. Policia Nacional. Turespanya.

Administracions Provincials i Locals

Ajuntament de Madrid. Ajuntament de Sevilla. Diputació de Barcelona. Generalitat de Catalunya. Generalitat Valenciana. Govern Vasc. Junta d’Andalusia. Osakidetza.



Telecomunicacions

Telcoplace constitueix l’oferta global de Getronics en el sector de les telecomunicacions, on les infrastructures són un factor indispensable pel client final. Gràcies a Telcoplace, Getronics ajuda a les empreses de telecomunicacions a oferir serveis avançats als seus clients.

Alguns dels clients del sector de les operadores de telecomunicacions i proveïdors de serveis són:

Referències Telcoplace

Broadnet. BT. Euskaltel. R Cable Gallego. Retevisión. Skypoint. Telefònica. Vodafone.



1.4.5. Estructura

A Getronics Iberia tenim dos tipus de jerarquies. Es realitza una divisió per zones, realitzant particions geogràfiques, depenent de la localització de les oficines. També tenim una jerarquia funcional, depenent del treball desenvolupat. En el següent diagrama ens mostra l’estructura general de Getronics Iberia:

Zona Zona Zona Zona Mèxic Portugal Centre Centre Nord Nord-Est

Assegurances

Industrial

Sanitat

Financer Clients Projectes Llatins

Americans

Tempiber

Direcció Econòmica i Financera

Direcció de Mitjans i Infraestructura

Direcció Técnica

R.R.H.H. Formació

Inform. Interna

Serveis Generals

Desenvolupament Corporatiu

Qualitat Direcció Adjunta

Marketing i Comunicacions

President

Vicepresident

Infraestructura Tècnica

Figura 2. Estructura de Getronics.



1.4.6. Localització

Getronics Iberia compte amb una xarxa d’oficines distribuïdes per tota la península Ibèrica. Té una forta presència local, seguint la política internacional de l’empresa, des d’on ofereix un servei directe al client. A més a més, aquesta xarxa d’oficines és un dels punts forts de les solucions d’infrastructures, que ens permet assumir compromisos de manteniment de forma directe (sense dependre de tercers) i ajudant als clients a que les seves infrastructures es converteixin en una avantatge competitiva.

A Portugal es disposa d’una oficina a Lisboa. A Espanya la seu central esta a Madrid, amb oficines a Almeria, Sevilla, Saragossa, Santander, Ciutat Reial, Burgos, Barcelona, Girona, Lleida, Tarragona, Castelló, València, Palma de Mallorca, Les Palmes de Gran Canària, Santa Cruz de Tenerife, Bilbao i San Sebastià.



1.5. Situació Dins de l’Empresa

Em trobo dintre de la zona nord-est, concretament a l’oficina de Tarragona. Dins de l’oficina estem sota el sector bancari treballant per l’àrea de mitjans de pagament.

SECTOR BANCASECTOR BANCARI

ÀREA D’INFRAESTRUCTURES

SECTOR FINANCER SECTOR INDUSTRIASECTOR INDUSTRIAL

ÀREA DE SERVEIS BANCARIS

ÀREA DE MITJANTS DE PAGAMENT

GETRONICS IBERIA (ZONA NORD-EST)

Pere Ferrer

Figura 3. Situació a l’Empresa.

L’ àrea de Mitjans de Pagament Electrònic (MPE) s’ocupa de la gestió dels moviments que es realitzen amb targetes, tant des del punt de vista de la targeta com des del punt de vista del comerç on es realitza el pagament.

Dins de l’àrea MPE l’entitat financera té diferents tipus de clients. Per un costat tenim el comerç, que sol·licita un terminal per poder realitzar el cobrament amb una targeta i per l’altre costat tenim el propietari de la targeta amb la que es vol realitzar l’operació.



Per diferenciar això, l’àrea de treball es divideix principalment en les següents aplicacions:

• MCC (Aplicació de Comerços): Es l’aplicació encarregada de gestionar les

operacions efectuades en un comerç o empresa que permetin els pagaments amb targetes.

• TCR (Aplicació de Targetes): Es l’aplicació encarregada de gestionar les

targetes de l’entitat financera. Proporcionant serveis sobre les targetes (alta, baixa, modificacions, etc.) i descomptant les operacions realitzades.

• TCO (Aplicació de Reclamació d’Operacions): Aquesta aplicació permet

gestionar les incidències realitzades sobre operacions, ja siguin des del punt de vista del titular de la targeta o del comerç. Si la targeta es pròpia de l’entitat financera l’aplicació permet iniciar l’incidència. Aquesta aplicació també rep les reclamacions de comerços propis, per part de les targetes gestionades per altres entitats financeres.



1.6. Comerç Electrònic

Tot aquest projecte no té sentit si abans no té una part electrònica que faciliti la realització d’aquests tipus de pagament i la seva posterior reclamació si fos el cas.

En aquest apartat, intentarem detallar els components electrònics que ens podem trobar, les seves característiques principals i com es comuniquen entre ells per tal de dur a terme un pagament.

1.6.1. Mitjans Pagament Electrònics

Detallarem els diferents elements que actualment les entitats financeres posen a la nostra disposició.

1.6.1.1. Targeta de Crèdit /Dèbit:

Sense cap mena de dubte, es tracta del mitja de pagament electrònic més conegut. Tot i que existeix una gran varietat de targetes en el mercat, les seves característiques físiques són iguals, ja que estan regulades per la norma ISO-7810/7811 on s’especifiquen totes les característiques que han de tenir les targetes de banda magnètica.

Normativa ISO

La normativa ISO (International Organization for Standardization) defineix les característiques físiques de les targetes en 3 formats bàsics:

CR-80 → 86 x 54mm (Estàndard Targetes Bancàries). CR-90 → 92 x 60mm. CR-100 → 95 x 67mm.

La norma ISO 7810/7811 defineix les característiques sobre la posició de la banda magnètica a la targeta, la tècnica de gravació i encriptació dels caràcters:

PISTA 1 → 79 caràcters alfanumèrics → 210 bpi1 . PISTA 2 → 40 caràcters numèrics → 75 bpi. PISTA 3 → 107 caràcters alfanumèrics → 210 bpi.

1 BPI : Bytes per polsada o bytes per inch. Unitat de mesura de densitat de registres de dades.



Car

Unabanes tlectel qemmles

Figura 4. Dimensions Targeta Bancària.

acterístiques Banda Magnètica

banda magnètica està formada per material magnètic combinat amb pintura. La da magnètica pot ser laminada o estampada a qualsevol superfície lliça, tal com roba a una targeta de crèdit. La informació és llegida o escrita a la cinta per un or/gravador. Un lector/gravador consisteix d’un capçal de gravació magnètica, ual pot llegir o gravar informació magnètica a la banda. La informació queda agatzemada a la banda en forma de codi binari. El material del que estan fetes

targetes de banda magnètica sol ser PVC, per la seva robustesa.



La banda magnètica és susceptible a alteracions o esborrat per causa d’altres camps magnètics. D’igual manera és susceptible a danys físics i a danys causats pel medi ambient. La necessitat de preveure el dany de l’informació mantinguda a una cinta com a resultat d’un contacte inadvertit amb camps magnètics que poden ser trobats durant l’ús diari d’una targeta ha portat a desenvolupar targetes amb propietats magnètiques més resistents. La resistència d’una banda magnètica ve donada per la seva coercitivitat (es mesura en oersteds), la qual es defineix com el camp magnètic necessari per esborrar una cinta codificada. Generalment, les targetes de baixa coercitivitat (300 oersteds) són més fàcilment canviades o codificades que les targetes d’alta coercitivitat. A l’hora de triar un nivell de coercitivitat existeixen limitacions, donat que les cintes amb una coercitivitat d’entre 3.000 i 5.000 oersteds poden ser difícils de llegir, gravar o modificar.

La coercitivitat de la targeta vindrà donada per l’aplicació on s’utilitzarà. A continuació podem detallar alguns exemples:

HI-CO (Alta aparcaments, eaplicacions amb

LO-CO (Baixpromocionals, bde targetes end’emissions de

Pel que fa al muna àrea neta, sei 80ºC. Les temp

Figura 5. Banda Magnètica.

Coercitivitat): Aplicacions de control d’accés i presencia, n entorns agressius amb una alta radiació de camps magnètics, períodes de validesa llargs (2 o 3 anys) sense renovar targeta, etc.

a Coercitivitat): Aplicacions de fidelitat, targetes comercials, ancàries i totes aquelles solucions que requereixen una renovació

períodes curts de temps o que requereixen un gran nombre targetes i per tant una reducció del cost final.

illor ambient de conservació per una targeta de banda magnètica és ca i freda. Les temperatures típiques d’emmagatzemat són entre 40 eratures típiques de treball són entre 0 i 55ºC.



Dades Targeta Bancària

Les targetes magnètiques bancàries tenen al seu exterior una sèrie de dades visibles que també es troben codificades a la banda magnètica. Però la banda magnètica conte informació que no es troba a l’exterior. Bàsicament a l’exterior d’una targeta trobem el número de la targeta, la data de caducitat i el nom del titular.

El número de la targeta sol ser de 16 xifres i rep el nom de PAN (Primary Account Number).

Si es passa una targeta bancària per un lector de bandes magnètiques, l’informació que obtindríem vindria a ser:

%B4847025030377523^PEREZ PEREZ JUAN ^0412101162910000000003091744291?* ;4847025030377523=04121011629109100000?= ;Altres dades ...

Les normes ISO defineixen la possibilitat de tenir fins a 3 tracks o pistes en una targeta bancària, que venen a ser les tres línies de la figura anterior. La banda magnètica d’una targeta la podríem veure com tres fraccions d’una cinta de cassette posades en paral·lel i cada una amb la seva informació. Quan es passa la targeta pel lector s’estan llegint aquestes tres pistes i com a resultat s’obtenen tres línies de dades. La tercera pista pot no tenir informació, però com a mínim ha de portar informació el track1 i el track2.

El track 1 i 2 (tracks només de lectura) s’utilitzen per validacions de transaccions, en canvi el track 3 (track de lectura i gravació) l’utilitza el banc o entitat que emet la targeta. Això significa que quan pagues amb una targeta, en principi el track 3 és transparent. L’informació important per validar la transacció està al track 1 i 2. En canvi, si vas al caixer de la teva entitat financera pot ser que realitzin una lectura o una gravació d’aquest tercer track.



Trac

Les d

Si re

%B48

2 LRC – Caràccompleixen am

Figura 6. Tracks d’una Targeta Bancària.

k 1

ades generals que formen el track 1 són les següents.

Dades Generals Longitud 79 caràcters (Inclou les

sentencia inici, final i LRC2) Joc de caràcters ALPHA (Números i lletres) Densitat del Bit 8,27 bits per mm (210 bpi) Codificació 6 bits més 1 bit de paritat Conjunt de Caràcters Space ! " # $ % & ' ( ) * + ,

- . / 0 1 2 3 4 5 6 7 8 9 : ; < = > ? @ A B C D E F G H I J K L M N O P Q R S T U V W X Y Z [ \ ] ^ _

Inici Sentencia % Final Sentencia ? Separador ^

cuperem l’exemple de lectura d’una banda magnètica.

47025030377523^PEREZ PEREZ JUAN ^0412101162910000000003091744291?*

ter de Redundància Longitudinal. Aquest caràcter ho porten codificat totes les targetes que b l’estàndard ISO, però molt pocs lectors l’utilitzen actualment.



I desglossem el contingut.

% B 4847025030377523 ^ PEREZ PEREZ JUAN ^ SS PAN FS Nom SS

0412 101 162910000000003091744291 ? * Data SC Discretionary Data ES Irc

Obtenim que les dades amb el fons blanc són fixes mentre que les dades que tenen el fons gris són variables. A continuació passem a descriure l’informació que tenim:

B → Una targeta bancària és un tipus de targeta ISO7811. Doncs bé, no existeix un únic format de codificació, el que veurem és un d’ells i és el format de codificació ‘B’. Aquest format sempre el trobarem si es tracta d’una targeta bancària.

PAN → És el mateix valor que podem trobar imprès a l’exterior de la targeta.

^ → Exerceix la funció de separador.

Nom → Existeixen 26 caràcters destinats al nom. Com es pot observar l’estructura que segueix el camp és: “Cognom1_Cognom2_Nom” on els guions baixos són espais. També podem trobar moltes vegades que s’utilitza la barra per separar el segon cognom del nom “Gognom1_Cognom2/Nom”. Si el nom té menys de 26 caràcters, s’acaba d’omplir aquest camp amb espais. Si conte més de 26 caràcters es talla el contingut per la dreta (Comença tallant o eliminant el nom). Com a curiositat, comentar que aquest camp pot no estar exactament igual a la banda magnètica que a l’exterior de la targeta. Ens podem trobar sobretot abreviatures per tal de donar cabuda al nom. Per exemple, podem trobar “J.Juan Perez Perez” i a la banda magnètica tenir “Perez Perez/José Juan “, o a la inversa. En resum, el nom que podem trobar a la banda magnètica no té perquè coincidir amb el nom que està estampat al plàstic de la targeta.

Data de caducitat → Són sempre 4 dígits i el seu format és AA/MM. És a dir, els dos primer dígits per l’any i els següents pel mes (la nostra targeta d’exemple caduca al desembre del 2004). A la banda magnètica trobem la data de caducitat al rebés de com està imprès al plàstic de la targeta.

SC (Service Code) → Aquests tres dígits defineixen les condicions d’utilització d’una targeta. Cada dígit té un significat i 10 possibles valors (0-9).



Discretionary Data → També pot rebre el nom de “DD” o “DisData”. Ho podem definir com un conjunt de caràcters lliures. Qui codifica la targeta pot omplir aquests camps amb l’informació que cregui oportuna. Lògicament en aquest camp és on es troben els valors claus per validar un procés de transacció.

En el nostre exemple el valor de la DD és:

162910000000003091744291

A continuació passarem a explicar el significat d’alguns dels camps que apareixen al DD. Els cinc primes dígits que trobem reben el nom de PVV (Pin Verification Value) i permeten validar el PIN. A partir de diferents dades de la targeta el sistema realitza una sèrie d’operacions on el valor resultant ha de coincidir amb 6291. El Valor 6291 no és el PIN sinó el resultat d’una sèrie d’operacions complexes per validar que el PIN introduït sigui el correcte. El ‘1’ inicial és el PVKI (Pin Verification Key Indicator), que indica al sistema quina clau utilitzar a l’hora de realitzar la validació.

L’utilitat principal del PVV és la validació Off-Line del PIN. En l’actualitat, les targetes solen dur aquest camp a 0 ja que normalment ja s’està fent sempre la validació del PIN On-Line.

Dins del DD podem identificar un altra valor anomenat CVV o CVC (“Card Verification Value” per les targetes Visa i “Card Validation Code” per les targetes Mastercard). El significat que té és el mateix per totes les targetes, només canvia el nom. Aquest valor ens serveix per validar que la targeta sigui bona i el procés de verificació és molt similar al que es realitza pel PVV. A partir d’una sèrie de valors de la targeta, es realitza una operació complexa i el resultat ha de ser el CVV per tal de que es consideri la targeta com a bona. A l’exemple que estem utilitzant tenim el valor del CVV a “091”.



Track 2

Les dades generals que formen el track 2 són les següents.


sentencia inici, final i LRC) Joc de caràcters BCD (Números) Densitat del Bit 2,95 bits per mm (75 bpi) Codificació 4 bits més 1 bit de paritat Conjunt de Caràcters 0 1 2 3 4 5 6 7 8 9 : ; < = > ? Inici Sentencia : Final Sentencia ? Separador =

Si recuperem l’exemple de lectura d’una banda magnètica.

;4847025030377523=04121011629109100000?=


; 4847025030377523 = 0412 101 1629109100000 ? = SS PAN FS Data SC Discretionary Data ES Irc

Obtenim que les dades amb el fons blanc són fixes mentre les dades que tenen el fons gris són variables. A continuació passem a descriure l’informació que tenim:



Data de caducitat → Són sempre 4 dígits i el seu format és AA/MM.

SC (Service Code) → Aquests tres dígits defineixen les condicions d’utilització d’una targeta.

Discretionary Data → Veiem que aquí és més fàcil diferenciar el CVV. Moltes vegades després del CVV està tot a zero i altres cops tenim informació. Una manera senzilla de localitzar aquest camp és comparar el track 1 amb el 2 fins trobar tres dígits consecutius iguals.



Track 3



sentencia inici, final i LRC) Joc de caràcters BCD (Números) Densitat del Bit 8,27 bits per mm (210 bpi) Codificació 4 bits més 1 bit de paritat Conjunt de Caràcters 0 1 2 3 4 5 6 7 8 9 : ; < = > ? Inici Sentencia : Final Sentencia ? Separador =

Aquests track es troba lliure per guardar l’informació que cregui necessària l’entitat emissora. CVV2 A parat del codi CVV que es troba gravat a la banda magnètica, existeix un CVV2. Aquest esta format per tes dígits i es pot trobar gravat a la part del darrera de la targeta entre banda magnètica i la signatura del titular. El CVV2 serveix per validar les transaccions no-presencials (bàsicament per internet o per telèfon). Es tracta d’una mesura antifrau que, d’alguna manera, permet donar més garanties que la persona que està utilitzant la targeta, la té físicament en aquest moment. A més a més, permet realitzar validacions sobre el PAN i la data de caducitat.



Estructura del PAN

La longitud del PAN més habitualment és de 16 dígits, tal com s’indica a la ISO-7812 (Les targetes Visa i MasterCard tenen aquesta longitud).

Si dividim el PAN en quatre parts.

4 84702 503037752 3 Indústria BIN Num. Targeta Check Dígit

Tenim que el primer dígit indica l’industria, ja que no només segueixen aquest estàndard les targetes de crèdit. Els diferents valors que pot tenir aquest dígit són:

0 Altres indústries. 1 Línies aèries. 2 Línies aèries i altres indústries. 3 Viatges i oci. 4 Indústria financera. 5 Indústria financera. 6 Indústria financera. 7 Petroli. 8 Telecomunicacions i salut. 9 Assignacions nacionals.

La següent part és el BIN (Bank Identification Number). Aquest número indica l’entitat financera que emet la targeta. Cada banc sol tenir varis BINs assignats. Tot i que estrictament el BIN són 5 números es sol considerar com a BIN els 6 primers dígits. Un banc o caixa d’estalvis sol comprar diferents BINs per diferenciar entre les seves targetes de crèdit o de dèbit o inclòs diferenciar diferents productes (Un visa clàssic sol tenir un BIN diferent a una Visa Or, encara que siguin del mateix Banc). A mode d’exemple podem veure una sèrie de BINs de diferents entitats Espanyoles.

450625 Caixa Madrid (Visa Clàssic) 454771 Caixa Catalunya (Visa Or) 460332 BBVA (Visa Electron) 484558 La Caixa (Visa Clàssic) 496626 La Caixa (Visa Or)



La següent taula ens indica els diferents rangs de BINs segons el tipus de targeta que podem trobar a l’actualitat. Al tractar-se d’una taula molt resumida, segurament no estaran representats tots els BINs que s’utilitzen, però el que es pretén mostrar és que una targeta que comenci per ‘4’ difícilment no serà un Visa. Una targeta que comenci per ’51-55’ bàsicament seran MasterCard i les que comencin amb un ‘3’ seran American Express.

Tipus Targeta Rang de BINs Visa 400000 – 499999 MasterCard 510000 – 559999

American Express 340000 – 349999 370000 – 379999

Novus Network 601100 – 601199

Diners Club 300000 – 305999 360000 – 369999 380000 – 389999

JCB Card 352800 - 358999

Desprès del BIN trobem un camp de 9 xifres on s’informa el número de la targeta. Aquest número ens permet diferenciar les diferents targetes que estan dins d’un mateix BIN.

Per últim tenim el dígit de control, que permet validar que el PAN sigui correcte. Quasi tots el aparell que llegeixen bandes magnètiques comproven aquest dígit de control. A partir del 15 primers números, aquest últim es genera aplicant una formula que es diu “Luhn” o “Mod-10” o “Modulus-10”. Aquesta formula es basa en l’assignació d’un pes específic a cada dígit tal i com es mostra a la següent taula.

Pes 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 Dígits 4 8 4 7 0 2 5 0 3 0 3 7 7 5 2 Productes 8 8 8 7 0 2 10 0 6 0 6 7 14 5 4 ‘XY’=’X’+’Y’ 8 8 8 7 0 2 1 0 6 0 6 7 5 5 4 Suma 8 + 8 + 8 + 7 + 0 + 2 + 1 + 0 + 6 + 0 + 6 + 7 + 5 + 5 + 4 = 67

Al valor 67 s’arriba seguint els següents passos:

1. Multipliquem cada número pel seu corresponent pes. 2. Si obtenim un valor d’una sola xifra, ho deixem igual. En canvi si el valor

és de dues xifres (10 o més) li sumem (12 = 1 + 2 = 3, 16 = 1 + 6 = 7 ...). 3. Sumem tots els resultats. Arribant així al valor que apareix a la taula

d’exemple.

Una vegada obtenim el valor resultant, agafem el següent múltiple de 10 (en el nostre cas 70) i li retem el valor obtingut. El resultat de la resta és el dígit de control. En el nostre cas és el ‘3’ (70 - 67).



Gravació i Lectura:

La cinta i el lector es comuniquen via camp magnètic. La lectura es porta a terme lliscant la targeta de banda magnètica a través del lector (encara que d’igual manera pot realitzar-se que el capçal es mogui al llarg de la banda magnètica de la targeta).

En el procés de lectura, es recullen el canvis de polaritat de la banda magnètica per mitja d’un capçalera magnètica. En el procés d’escriptura, la capçalera magnètica crea un camp magnètic que altera la polarització d’una petita regió de la banda, i d’aquesta manera pot escriure informació. L’intercanvi de dades entre la targeta i una unitat de lectura/gravació típica, sol tenir una velocitat propera a 12.000 bits per segon.

Figura 7. Sistema de Gravació i Lectura.



Al passar la targeta prèviament gravada sobre una capçalera magnètica de lectura, aquesta generarà una tensió proporcional a la variació de flux.

Figura 8. Senyals en una Lectura de Banda Magnètica

Tècniques de Codificació:

La tècnica de codificació utilitzada per la gravació/lectura de les targetes de banda magnètica va ser desenvolupada per Aiken al 1954 i és coneix com "Two-Frequency Coherent Phase Recording" (Gravació de Fase Coherent i dos Freqüències). Aquest mètode permet la gravació de dades de manera sèrie sense necessitat de polses de sincronia en un canal separat i amb la possibilitat d’utilitzar una velocitat de lectura variable.

En la següent figura podem observar que la permanència a nivell alt (H) o baix (L) d’un pols de rellotge fins al pròxim pols de rellotge significa que la dada és un 0. Si hagués una transició de H a L o de L a H entre pols de rellotge, a les hores el bit gravat és un 1.

Figura 9. Codificació Dades Banda Magnètica



Avantatges i Desavantatges:

Per explicar aquest punt, parlarem de les avantatges i desavantatges que presenten les targetes de banda magnètica, juntament amb les solucions que existeixen per la millora del sistema.

Desavantatges:

1. La capacitat de dades és baixa. Poden aparèixer problemes d’espai en aplicacions que requereixen molta informació ja que, com ja s’ha comentat, el màxim número de caràcters d’una pista és de 107, i el màxim de la targeta (utilitzant les 3 pistes) és de 226.

2. La targeta magnètica especificada pels estàndards ISO és vulnerable a la pèrdua

de dades a causa de camps magnètics produïts per fonts magnètiques molt comuns, com els imants a petites quantitats. Aquesta vulnerabilitat de les cintes magnètiques convencionals de baixa coercitivitat deguda al dany magnètic redueix el número d’aplicacions potencials per la targeta. Per exemple, a ningú li agradaria “portar diners” (com és el cas del moneder electrònic) en una targeta que pugui danyar-se fàcilment tenint com a conseqüència la pèrdua d’aquest “diners”.

3. La fiabilitat a l’hora de realitzar lectures de les targetes és pobre, amb un

percentatge típic d’error en les transaccions del 10%. Es pot considerar que un gran nombre d’aquests errors en les transaccions és degut a la desmagnetització de les targetes. Aquesta desmagnetització és deguda a la baixa coercitivitat dels materials magnètics utilitzats.

4. Els estàndards ISO poden ser fàcilment copiats, falsificats i duplicats.

Avantatges:

1. Existeixen diferents iniciatives a la indústria per incrementar la capacitat de dades a les targetes de banda magnètica. L’objectiu és crear una targeta de banda magnètica amb major capacitat.

2. La pèrdua de dades degut als camps magnètics comuns pot ser resolta amb la

utilització de materials a les bandes magnètica d’alta coercitivitat, del rang dels 3000 a 4000 oersteds. Algunes de les principals aplicacions on s’utilitzen les cintes d’alta coercitivitat són els sistemes de transport (bitllets de tren, metro, etc.).



3. La fiabilitat pot ser millorada amb la utilització intel·ligent de tècniques i codis

de correcció d’errors. Per exemple, la verificació de la redundància longitudinal (LRC) és codificada a totes les targetes que compleixen amb l’estàndard ISO, però només uns pocs lectors del mercat l’utilitzen actualment..

4. Tenim sistemes molt més avançats que proporcionen una millora a la fiabilitat

de lectura, de tal manera que es pot llegir una targeta amb una passada de longitud d’una polsada.

Les companyies fabricants segueixen buscant millores en la seguretat de les targetes de banda magnètica. Cada una d’aquestes tècniques proporcionen protecció contra el frau degut a la copia i alteració. Quan obtenen noves tècniques s’envien a Mastercard, Internacional i Visa Internacional perquè avaluïn si creuen convenient que s’implementin en les seves targetes de crèdit.

1.6.1.2. Targeta Moneder

Aquest dispositiu es coneix com a moneders electrònics i es basen amb les especificacions CEPS (Especificacions Comuns de Moneder Electrònic). En l’actualitat es troben obsolets, no per la seva tecnologia, sinó per la poca acceptació que va tenir dins del mercat. La utilitat que tenia la targeta amb xip moneder, era captar els petits pagaments que es realitzaven habitualment.

El moneder electrònic consistia en una targeta que incorpora un petit xip on s’emmagatzema un valor monetari que es pot utilitzar en qualsevol comerç amb un lector d’aquest tipus. Un clar exemple d’aquest dispositius és la targeta telefònica, amb l’inconvenient que l’import que es recarrega només es pot utilitzar per realitzar trucades.

Descripció i Funcionament:

Les targetes de xip moneder més habituals contenen una PROM de 256 bits, organitzats en 256 direccions de 1 bit. El direccionament a la PROM el realitza un circuit de 8 bits, de tal manera que quan el comptador està a la direcció n, podem llegir o escriure en aquesta posició n. Per avançar a la següent direcció, només s’ha d’aplicar un pols a l’entrada de rellotge del comptador, i aleshores, aquest apuntarà a la següent direcció n+1. Existeix, a més a més una entrada de reset que posa a zero el comptador. A més a més, el comptador de direccions és cíclic, de manera que si estàs a la posició 20 i volem accedir a la 18, podem fer un reset i donar 18 polsos de rellotge, o bé no utilitzar el reset i donar 254 polsos de rellotge. Quan una targeta es introduïda en el lector, aquest llegeix la zona reservada i comprova si la targeta es coneguda i quines dades té. Si la targeta és vàlida, va llegint la resta de la targeta per obtenir les dades que porta escrites.



Podem considerar que una targeta intel·ligent convencional, té els següents contactes:

Figura 10. C

Avantatges i Aplicacions:

Un dels principals avantatgepot operar sobre targetes de a PC’s o bases de dades per decisió de qualsevol operacipot obtenir d’una altra font.

Aquests tipus de targetes pmitjançant PIN (Personal Idsent bàsicament memòries.

Altres possibles aplicacions

1. Realitzar un control

de targetes intel·ligen2. Control de presència 3. Activació de maqui

maquinària perillosa,4. Targeta de garantia d5. Targeta moneder per

poden ser telèfons, m6. Control de consum d

Aquests dispositius tenen unels autònoms i els que van camb un terminal portàtil i econnexió clàssica RS232.

Patilla Significat 1 GND 2 Vpp: Tensió de Programació (+21V) 3 Dout: Sortida de Dades 4 No utilitzada 5 RST: Reset (Activat a nivell baix) 6 CLK: Clock (Actiu en flanc de baixada) 7 Din: Entrada de dades 8 Vcc: Voltatge d’Alimentació (+5V)

onnexions Targetes Intel·ligents.

s és l’autonomia que tenen. Qualsevol lector autoritzat xip sense necessitat que existeixin connexions físiques un determinat tipus d’operacions. D’aquesta manera, la ó radica al mateix lector, i no a la resposta que el lector

oden ser de lectura lliure o amb un control d’accés entification Number), però en els dos casos segueixen

d’aquests tipus de targetes, podrien ser:

de la producció d’una empresa amb un senzill sistema ts. i accessos. nària per personal concret, com poden ser alarmes, etc. e producció. utilitzar en aparells existents dintre de l’empresa, com enjadors, etc. ’aigua i energia durant la producció.

a fàcil implantació. Existeixen dos tipus de perifèrics: ontrolats per PC. Els autònoms poden reprogramar-se

ls que van connectats a un PC, ho fan per mitja d’una



1.6.1.3. Pagament amb Mòbil

Aquest sistema permet utilitzar el telèfon mòbil per tal de confirmar una transacció. Aquest sistema és molt útil pels pagaments a través de TPV’s virtuals que ens podem trobar a internet. En el moment que es demana la forma de pagament, es pot donar l’opció de realitzar el pagament amb mòbil. Si el titular té activada aquesta modalitat de pagament amb la seva entitat financera, podrà introduir el número del telèfon i d’aquesta manera no té els recels que provoca introduir un número de targeta de crèdit en una plana d’internet Una vegada el TPV virtual transmet el càrrec al centre autoritzador aquest telefona al titular per tal que confirmi l’operació introduint el número PIN (Número d’Identificació Personal) de la seva targeta. Una vegada es valida que el número PIN és el correcte, l’operació queda autoritzada. Aquesta comunicació es realitza a través de la xarxa GSM (Groupe Special Mobile) de les diferents companyies nacionals i el PIN es transmet com un codi més d’aquesta xarxa.

Figura 11. Pagament amb Mòbil

Característiques:

• Es tracta d’un sistema considerat NO segur. • No requereix tenir un software específic. • Es pot implementar per qualsevol tipus de targeta. • Té una implementació senzilla al comerç. • Té un cost elevat per l’entitat degut a les trucades.



Dins del pagament amb mòbil podríem integrar els que disposen de tecnologia WAP (Wireles Application Protocol). És a dir, si un usuari amb un telèfon amb aquesta tecnologia decideix realitzar una compra a una plana WAP, la confirmació de l’operació no es realitzarà a través d’una trucada per la línia GSM tradicional, sinó a través de la mateixa comunicació WAP que ja està establerta.

Figura 12. Pagament a una plana WAP.



1.6.1.4. Targeta Intel·ligent

En l’actualitat, està molt estès l’ús de les targetes amb xip. Aquesta denominació agrupa diferents tipus de targetes que les seves úniques característiques comuns són la seves dimensions (com una targeta de crèdit convencional) i la inclusió d’un xip en lloc de la banda magnètica com a mitja per emmagatzemar dades. Les targetes xip poden està destinades a una utilització molt diversa, i els xips que utilitzen poden anar des d’un simple PROM fins a sistemes basats en microcontroladors capaç de codificar i emmagatzemar dades amb alt nivell de seguretat.

Actualment, s’està preparant la implantació per part de les entitats financeres d’aquest tipus de targetes dins del pagament electrònic, amb l’objectiu d’anar substituint les targetes de banda magnètica d’una manera progressiva. Aquestes targetes permeten emmagatzemar en un mateix suport i d’una manera electrònica, tota una sèrie d’informació ja sigui de caràcter financer com no financer i protegir aquestes dades d’usuaris no autoritzats. Amb una sola targeta és possible disposar d’un ampli ventall de serveis: Pagament de transport públic, pagament de cabines telefòniques, disposar d’un moneder amb diferents divises, comprar per internet d’una manera segura, identificar-se per accedir a zones restringides, emmagatzemar informació sobre historial mèdic, comprar a través de la televisió, etc.

Ja es disposa de dos sistemes operatius que ha desenvolupat SERMEPA (Servei de Mitjans de Pagament) pel control del xip financers, i reben el nom de TIBC (Targeta Intel·ligent de Bancs i Caixes) i Advantis:

• TIBC: És un sistema operatiu multiaplicació i multidivisa. Aquest sistema operatiu és el que controla, entre altres funcions, l’accés a l’informació emmagatzemada a la memòria de la targeta.

• Advantis: És un sistema operatiu multiaplicació i multidivisa, habilitat per

donar servei a la tecnologia sense contactes (radiofreqüència). Aquest sistema permet traslladar funcions de crèdit i dèbit des de la banda magnètica al xip. També permet incloure al xip funcions complementaries com targetes per universitaris, controls d’accessos, etc.



Característiques

Entre totes les avantatges que pot tenir una targeta intel·ligent respecte una targeta de banda magnètica en podem destacar les següents:

• Cost de la transacció : Les bandes magnètiques necessiten connectar-se

amb el Host per tal de poder autoritzar una operació. Aquesta connexió amb el Host té un cost que en ocasions pots ser important. La targeta intel·ligent, és similar a un ordinador. El xip és un element de caràcter actiu, que es capaç de realitzar operacions per si mateix, podent emmagatzemar gran quantitat d’informació, realitzar operacions amb la mateixa i amb altres informacions que li pugui proporcionar el dispositiu amb el que es posa en contacte en cada moment. Aquest simple fet possibilita que una part quantitativament important de les transaccions puguin realitzar-se sense necessitat de telecomunicacions, aconseguint amb això un estalvi substancial en cada transacció per part del comerç.

• Seguretat: El contingut de la banda magnètica, per la tecnologia que implica, pot ser llegit i pot ser manipulat per persones amb coneixements i mitjans adequats amb relativa facilitat. El xip, conte una tecnologia interna molt més sofisticada que fa que les possibilitats de manipulació física es redueixin completament. A més a més, per la seva capacitat interna, es capaç de participar i suportar processos criptogràfics molt complexos.

Les dades emmagatzemades en una targeta intel·ligent estan protegides per sofisticats mecanismes de seguretat. Per això, resulta molt difícil modificar fraudulentament les dades o copiar les targetes. Passar de targetes de banda magnètica a targetes intel·ligents redueix considerablement els fraus deguts a la falsificació de targetes.

• Capacitat d’emmagatzemen: La capacitat d’informació incorporada a una banda magnètica es petita i estàtica, per lo que la relació entre l’usuari de la targeta i l’emissor és molt unidireccional. Únicament s’actualitza quan s’interactua a través de hardware sofisticat. El xip, amb la seva major capacitat d’informació, té la possibilitat de gestionar informació amb el que s’obren noves possibilitats per la relació entre l’usuari i l’emissor de la targeta.

El desenvolupament de les tecnologies per múltiples aplicacions, implica que varies aplicacions diferents puguin residir al mateix temps en una sola targeta: targetes de crèdit/dèbit, moneder electrònic, bitllets de viatge, punts de fidelització, identificació de seguretat, etc.



• Flexibilitat: La tecnologia de targetes intel·ligents es compatible amb el

principals tipus de sistemes operatius. També permet un entorn de programació que permeti crear, emmagatzemar o suprimir aplicacions a les targetes, lo que significa que és possible fer targetes “a mida” seleccionant per la targeta les aplicacions que s’adapten a les circumstancies i necessitats de cada persona.

Com a desavantatge d’una targeta intel·ligent respecte una targeta de banda magnètica podríem destacar:

• Cost: Els cost de produir una targeta amb xip és aproximadament de 8 euros

per targeta, mentre que el cost de les targetes de banda magnètica és de 10 cèntims de euro per targeta. Cal aclarir que aquests costos no els ha d’assumir directament l’usuari, sinó l’entitat que adquireix aquest tipus de producte.

• Dispositius addicionals: Per realitzar operacions segures des de casa (per

internet, telèfon, etc.) és necessari tenir un lector, el qual s’ha de proporcionar amb la targeta financera. El lector és un dispositiu electròniques s’instal·la al PC personal i actua com intermediari entre l’ordinador i el xip.

Podríem considerar que l’estructura interna d’una targeta intel·ligent vindria a ser la següent:

.

Figura 13. Diagrama de Blocs del xip.



1.6.1.5. Targetes de Radiofreqüència (Teletac)

La tecnologia de targetes amb Radiofreqüència ha permès desenvolupar el conegut sistema Teletac. Aquest sistema s’ha desenvolupat bàsicament pel pagament de peatges d’una manera còmoda i sense la necessitat de parar.

Es tracta d’un petit transmissor, amb un dispositiu de codificació electrònica, que conte les dades de l’usuari i li permet el pas per les vies de peatge sense parar-se.

Aquest dispositiu es posa al parabrises del vehicle, lleugerament separat del marca del vidre.

El funcionament és molt senzill, quan el vehicle s’aproxima al telepeatge, una antena activa el Teletac, el qual transmet les dades de l’usuari. L’ordinador de la via les llegeix i dona l’ordre per permetre el pas o desviar el vehicle a una altra via si detecta alguna anomalia.

Quan s’utilitzen aquests dispositius i per tal que la comunicació sigui correcta entre l’emissor i el receptor, s’ha de mantenir una distancia de separació respecte el vehicle del davant i moderar la velocitat.

Tecnologia de Radiofreqüència:

La tecnologia d’identificació per radiofreqüència (RFID) és un sistema d’identificació automàtic que no precisa contacte, és la tecnologia més nova i de més ràpid creixement en el segment d’identificació automàtica a l’industria. RFID permet la identificació automàtica, localització i monitorització de persones, objectes i animals amb una infinitat d’aplicacions que van des de simple inventari fins a sistemes complexos de cobraments de peatges a autopistes.

La tecnologia RFID ha revolucionat la indústria de la identificació automàtica oferint avenços significatius en comparació amb sistemes tradicionals com codis de barres, targetes de banda magnètica i xips de contacte o proximitat.

Funcionament:

De la manera més simple, un sistema RFID integra un número d’identificació únic en un petit microxip, i aquest serà instal·lat amb l’objecte que es vol identificar.



El microxip s’activa solament quan hi ha un senyal de radio a una freqüència específica enviada per un lector o transmissor. Quan el microxip està actiu, immediatament respon enviant una senyal de radio modificada que conté el número d’identificació del microxip en qüestió.

El lector o transmissor realitza la funció de radio transmissor i radio receptor. Quan el microxip respon a la senyal i envia el seu número d’identificació, el lector pot automàticament enviar un senyal a una computadora pel seu processament. Aquest sistema té l’avantatge sobre altres sistemes d’identificació automàtica que no requereix línia de vista o contacte físic del lector amb el microxip per ser llegits. Encara que a la tecnologia RFID els microxips, antenes i lectors són el nucli del sistema, casi sempre són una part molt petita de tota la solució. Els sistemes RFID generalment abarquen computadors, programari, xarxes i sistemes de comunicació a més a més dels lectors i els microxips.

Beneficis:

1. Rapidesa i exactitud: RFID és ràpid. El microxip i el lector es comuniquen en mil·lisegons. El temps depèn de la comunicació amb la computadora central, però el temps total sol està entre 30 i 100 mil·lisegons.

2. No necessita contacte: Que existeixi visibilitat i contacte físic no és necessari.

La posició del lector en relació al microxip no és important, es a dir, és possible posar el microxip per sota, sobre o tapat per un altra material.

3. Fiabilitat: RFID és extremadament fiable en quan al rang d’errors.

4. Robustesa i baix manteniment: Degut a que RFID es pot llegir a través de

qualsevol material no metàl·lic, els components interns (microxips, antena, lectors) es poden empaquetar de manera que poden ser resistents a tot tipus d’ambient. Alguns resisteixen des de –40ºC fins 200ºC. Poden ser llegits a través de la brutícia, pintura, ciment, etc. Altres tecnologies automàtiques com el codi de barres, la banda magnètica o els xips de contacte requereixen una neteja constant i han de treballar en ambients sense grassa. RFID pot treballar en ambients humits, amb grassa o amb olis. A més a més, al no tenir parts mòbils, els microxips no requereixen manteniment.



Aplicacions:

1. Control d’accés, Seguiment, Monitorització de Persones: La tecnologia RFID permet tenir controlat i localitzat el personal dins d’una empresa, sense necessita que aquest tingui d’estar pendent d’identificar-se en cada moment. Ja que aquesta identificació s’està realitzat només pel fet de portar el microxip al damunt.

2. Control d’accés de vehicles: La tecnologia RFID s’ha estat utilitzant en el mon

de l’automòbil per l’accés dels vehicles a estacionaments, colònies privades i per el control de tràfic i de rutes de flotes. Un sistema RFID pot ser posat per monitoritzar qualsevol entrada o sortida d’estacionament. La tecnologia RFID no requereix de contacte i li dona al vehicle accés sense que el conductor es tingui que para a inserir una targeta o pressionar un boto. El microxip pot estar dintre d’una targeta o posat en el vehicle quan entra a l’estacionament o zona restringida. Cada vegada que passa un vehicle, el microxip es detecta per un lector, el qual envia un senyal que obre la barrera per donar accés lliure d’entrada o sortida al vehicle.

3. Automatització de plantes industrials: La tecnologia RFID té un gran valor

en aplicacions on els microxips poden ser utilitzats per identificar i localitzar contenidors o equips específics. Un sistema RFID pot verificar la correcta posició dels components o controlar l’operació d’un procés seqüencial, o iniciar l’acció apropiada en una estació de treball. Tota la informació recol·lectada pot ser ràpidament emmagatzemada a la computadora central. Després que un producte deixa la planta, els microxips poden ser utilitzats com a control de sortida, distribució i suport de garantia.

4. Manipulació de materials en magatzems: Amb els sistemes RFID les

aplicacions de manipulació de materials passen a ser sistemes simples de localització de materials amb sistemes RFID que optimitza el servei al client, espai, mà d’obra i equips. Els sistemes d’identificació automàtica poden rastrejar o monitoritzar totes les funcions bàsiques que un magatzem pot realitzar: recepció, emmagatzematge, recol·lecció i càrrega de productes. Els terminals portàtils de RFID llegeixen un senyal de radio emesa pel microxip. Té la fiabilitat de llegir informació i per mitja de comunicacions inalambriques enviar l’informació directament a una base de dades evitant teclejar l’informació i els possibles errors d’entrada en recepció de càrregues. Al ser portàtils fa que es tingui una gran cobertura dins d’un magatzem. D’aquesta manera es pot saber exactament quins materials es troben en un magatzem en qualsevol moment que es requereix.



5. Identificació de personal: El repte que han enfrontat les empreses privades

amb el govern és la necessitat d’identificar de manera segura, eficient i amb un cost-benefici rentable a persones. Eliminar la duplicació de targetes a només una targeta individual per usuari, verificar que aquest usuari entra ràpidament i sense sistemes de seguretat molt costós, o simplement garantir que no existeixen falsificacions de targetes, això és possible amb un sistema RFID. Els sistemes de seguretat biomètrics d’identificació són una solució versàtil i amb un excel·lent cost-benefici. El sistema biomètric combina RFID i tecnologia biomètrica per digitalitzar les empremtes del dit o de la mà en un microxip, donant una identificació a cada usuari. No es requereix d’informació externa, obtenint així absoluta privacitat per l’individu. Quan es crea una targeta d’identificació, la persona posa el seu dit o la seva mà en un escaner que converteix la impressió obtinguda en un número únic. Aquest s’emmagatzema a la targeta i posteriorment treballa com el número d’identificació (PIN) que opera en altres sistemes similars. A més a més de la impressió de l’empremta del dit o de la mà, el xip de la targeta pot contenir més informació si es requereix. En cada lloc d’identificació la persona simplement ha de posar la seva mà o dit a l’escaner i portar amb ell la targeta. La impressió de l’escaner es digitalitza i es converteix en un número que al comparar amb el número del xip de la targeta podrà permetre o negar l’accés. Els beneficis d’un sistema biometric són assegurar que la persona que té les seves dades en el xip de la targeta és l’única persona que pot utilitzar la targeta. Es té un sistema de seguretat molt sofisticat sense necessitat que existeixi un sistema central de base de dades que tingui que verificar la informació de cada punt d’identificació. A més a més es pot validar que una persona no intenta sol·licitar una nova targeta sota una identitat diferent.

6. Transport: La tecnologia RFID permet a vehicles, camions, tràilers i

contenidors ser identificats quan s’estan movent. Aplicacions de RFID es poden trobar en tots els sectors del transports inclòs l’administració de vehicles en un inventari, manteniment simple, control de flux de tràfic, estacionament i recol·lecció de pagament en peatges d’autopistes. Un exemple a l’identificació de vagons de ferrocarril seria la instal·lació de microxip als diferents vagons i amb lectors instal·lats estratègicament al llarg de les vies per poder tenir controlades totes les mercaderies.

7. Control d’actius: RFID es pot utilitzar en les organitzacions com un

component bàsic per preveure robatoris i per identificar i controlar actius. RFID dona una identificació permanentment la qual pot ser posada de tal manera que sigui virtualment indetectables i amb molta fiabilitat. Per augmentar la seguretat els microxips poden ser instal·lats durant el procés de manufactura, ideal per cuidar objectes de molts valors com equips electrònics, vehicles, equipaments pesats, substàncies perilloses, etc.



1.6.2. Mitjans Cobrament Electrònics

En aquest punt explicarem els diferents dispositius que existeixen per poder realitzar el cobrament amb mitjans de pagament electrònics .

1.6.2.1. Bacaladera

Es tracta d’un dispositiu no electrònic que permet realitzar el cobrament amb targetes de crèdit. Per aquest tipus d’operacions es disposa d’un imprès on es queden marcades les lletres que porten en relleu totes les targetes de crèdit. Posteriorment es complimenta l’import i el titular signa per donar la seva conformitat. Una vegada finalitzada la transacció, el comerç ha de portar l’imprès a l’entitat financera on s’introdueix manualment l’operació dins del sistema informàtic i s’ingressi l’import al compte del comerç.

Com és evident es tracta d’un sistema “Off-Line” que no disposa de cap sistema de seguretat. En l’actualitat es realitzen molt poques operacions amb aquest sistema.

1.6.2.2. Terminal Punt de Venda On-Line

El terminal punt de venda o datàfon és un dispositiu electrònic que permet acceptar el cobrament amb targeta.

Aquests aparells permeten realitzar una sèrie d’operacions bàsiques:

• Vendes. • Anul·lacions. • Devolucions. • Duplicat d’operacions. • Extracte d’operacions del TPV. • Consulta de totals. • Totalitzacions.



TPV Convencional:

Es tracta del TPV que podem trobar a qualsevol botiga. Aquest aparell es comunica a través de les línies RTC (Red Telefonica Conmutada) convencionals. Aquest tipus de línies només permeten establir una comunicació simultània i per tant, mentre s’està realitzant un cobrament no es pot iniciar un altre fins que no finalitza la transacció.

Figura 14. TPV’s Convencionals.

TPV ADSL:

Es tracta d’un sistema ideat per tal de permetre realitzar un cobrament ràpid a partir de les solucions ADSL (Asymmetrical Digital Subscriber Line). Aquests aparells es connecten a la línia per mitja d’un router i permet tenir varis TPV’s connectats simultàniament.

Les característiques principals són:

• Increment molt important de la velocitat de les transaccions. • Cobrament simultani de varis TPV’s • Un estalvi important pel comerç en trucades, ja que aquestes es realitzarien

a través de la tarifa plana ADSL.

Figura 15. TPV amb Solucions ADSL.



TPV GSM:

Aquests dispositius permeten realitzar operacions amb targetes tenint una total mobilitat del TPV.

Les característiques principals són:

• Permet realitzar operacions On-Line. • Terminal portàtil que funciona a través de la xarxa GSM. • Incorpora impressora per imprimir el tiquet. • Funcionament idèntic a qualsevol altre TPV.

Figura 16. TPV GSM.

1.6.2.3. TV Interactiva:

Les plataformes de televisió interactiva disposen d’uns serveis coneguts amb el nom de pay per view (pagament per visió). L’usuari pot contractar aquest servei trucant directament a la companyia subministradora del servei o bé, si el seu aparell ho permet, pot realitzar el pagament amb targeta de crèdit.



Alguns d’aquests aparell disposen de lector de banda magnètica i permeten connectar-se a la xarxa RTC convencional. Una vegada s’introdueix la targeta de crèdit al terminal i seleccionem quin producte volem adquirí per mitja del comandament a distancia, aquest realitza una trucada al centre emissor que gestiona la TV el qual s’encarrega de transmetre l’operació a l’entitat financera.

Una vegada l’entitat financera autoritza l’operació, es permet que l’usuari pugui veure la programació seleccionada.

En aquest cas el receptor de TV no es connecta directament a l’entitat financera com faria un TPV, sinó transmet les dades necessàries perquè el centre gestor de la TV pugui sol·licitar la transacció.

Figura 17. Pagament per Visió.



1.6.2.4. Terminal Punt de Venda Off-Line

Existeixen alguns terminals punt de venta que no realitzen una validació On-Line de les targetes amb el risc que això comporta. El cas més clar on s’utilitzen aquest tipus de terminals són els peatges de les autopistes on no és possible realitzar una validació de l’operació On-Line pel temps que comportaria i les cues que això provocaria.

Els dispositius Off-Line solen portar a la seva memòria un llistat de targetes fraudulentes que s’actualitza amb molta freqüència per tal d’evitar el frau dins del possible.

Tot i l’existència de comunicacions molt ràpides com podria ser la fibra òptica, el gran volum d’operacions que poden arribar a realitzar aquest tipus de terminal no fan recomanable la migració a un sistema de validació On-Line. En el cas de les autopistes, aquesta comunicació podria ocasionar grans retencions als usuaris.

1.6.2.5. Caixers Automàtics

Existeixen una gran varietat de caixers que es poden diferenciar pel seu disseny físic com per les funcions que realitzen.

Com a norma general, aquest dispositius porten un o més lectors de banda magnètica per tal de poder operar amb targetes i llibretes.

Podríem agrupar els caixers en tres tipus:

• Caixer estàndard: És el caixer que podem trobar a totes les oficines de les

entitats financeres i que permet realitzar una gran quantitat d’operacions. • Caixer desplaçat: Es tracta d’un caixer d’unes dimensions més reduïdes,

que té bàsicament la funció de tenir disponible diners en efectiu en llocs on no es troba cap oficina (centres comercials, Casinos, mercats, etc.).

• Caixer Interactiu: A part de totes les propietats que tenen els caixers estàndards, aquest tipus de caixers permeten realitzar funcions fora de l’àmbit financer com la compra d’entrades, el pagament d’impostos, etc.



Sistemes Operatius:

Actualment la major part dels caixers automàtics funcionen amb el sistema operatiu OS/2 d’IBM. Encara que també podem trobar alguns caixers, en especial els interactius, que funcionen amb Windows NT

Les entitats financeres pretenen passar progressivament tots els caixers automàtics que funcionen sota OS/2 a Windows, ja que aquest sistema operatiu permet implementar noves funcions amb relativa facilitat i permet que els caixers passin a ser compatibles amb les xarxes internes de les diferents entitats.

El Windows que Microsoft desenvolupa pels caixers automàtics, és en realitat, una versió reduïda que no conté res que es pugui semblar a un servei web. D’aquesta manera es pretén millorar els problemes d’estabilitat i seguretat que puguin tenir aquests sistemes operatius.

1.6.2.6. TPV Virtual

Es tracta d’un dispositiu dirigit als comerços ubicats a internet, els quals volen permetre el pagament amb targeta d’una manera fàcil i segura.

En les transaccions que és realitzen per internet, la seguretat és un dels principals aspectes que els titulars, comerços i entitats financeres persegueixen. Es tracta d’una qüestió molt important ja que la targeta és el mitja de pagament més utilitzat i aquests tipus de transacció es realitza de forma remota.

Els titulars volen realitzar les operacions tenint la certesa que l’informació que subministra (informació personal i de pagament) viatjarà xifrada i no podrà ser capturada per terceres persones no autoritzades. Per una altra part, els comerços volen tenir unes garanties de pagament.

Actualment els principals sistemes de seguretat que proposen les diferents marques de targetes són Verified by Visa i MasterCard SecureCode.

Aquest sistemes verifiquen d’una manera segura l’identitat del titular dels seus productes per realitzar compres en comerços virtuals. Per aconseguir aquest objectiu, el titular ha de registrar-se com a usuari d’aquest servei a la seva entitat.



Durant el registre, el titular crearà una contrasenya associada a la seva targeta que la podrà utilitzar quan realitzi les seves compres per internet. D’aquesta manera, sempre que utilitzi la seva contrasenya, obtindrà una protecció addicional i podrà confirmar d’una manera segura que és ell i no una tercera persona no autoritzada qui realitza la transacció.

Verified by Visa i MasterCard SecureCode estan basats amb la tecnologia 3D Secure i, a més a més de verificar d’una manera segura l’identitat dels titulars, proporcionen confidencialitat i integritat al processar compres On-Line gràcies a l’utilització de protocol SSL (Secure Sockets Layer).

Figura 18. Transaccions amb TPV Virtual.



1.6.3. Comunicacions

Es pretén donar una visió general d’alguns dels sistemes de comunicació que s’utilitzen en el comerç electrònic.

1.6.3.1. ADSL:

ADSL (Línia d’Abonat Digital Asimètrica) és una tecnologia basada en una línia telefònica convencional, que permet assolir altes velocitats aprofitant l’espectre de freqüències no utilitzades pel transport de la veu. Les línies ADSL aprofiten aquest espectre per establir dos canals de dades (usuari - xarxa i xarxa - usuari), que permeten la transmissió a alta velocitat, amb accés permanent. Gràcies a la separació entre les dades i la veu és possible aplicar diferents tarifes depenent dels servei que s’utilitza (Veu o internet).

Sota el nom de xDSL es defineixen una sèrie de tecnologies que permeten l’utilització d’una línia de telèfon estàndard (la que es pot trobar a qualsevol domicili) per transmissió de dades a alta velocitat i, al mateix temps, l’ús normal com a línia de telèfon. S’anomena xDSL (HDSL, ADSL, RADSL, VDSL) ja que tots aquests sistemes tenen un mateix tipus de funcionament, però diferents característiques en quant a prestacions (velocitat de la transmissió de dades) i distancia màxima del domicili a la central xDSL (el cable telefònic no es va dissenyar originalment per aquest tipus de servei, per la qual cosa, a major distancia menors prestacions). Entre aquestes tecnologies, la més adequada per una utilització domèstica es la que s’anomena ADSL. En el servei ADSL, l’enviament i recepció de dades s’estableix des de l’ordinador de l’usuari a través d’un mòdem ADSL. Aquestes dades passen per un filtre (splitter), que permet la utilització simultània del servei telefònic bàsic (RTC) i el servei ADSL. És a dir, l’usuari pot parlar per telèfon a la vegada que està navegant per internet. ADSL utilitza tècniques de codificació digital que permet ampliar el rendiment del cablejat telefònic actual. Per aconseguir aquesta tassa de transmissió de dades, la tecnologia ADSL estableix tres canals independents sobre la línia telefònica estàndard: dos canals d’alta velocitat (un de recepció de dades i un altre d’enviament de dades). I un tercer canal per la comunicació normal de veu (servei telefònic bàsic). Els dos canals de recepció de dades tenen major velocitat que el canal d’enviament de dades.



El caràcter asimètric d’aquesta tecnologia s’adapta perfectament a internet, ja que els usuaris de la xarxa solen rebre (velocitat de baixada o descarrega) molta més informació de la que envien (velocitat de pujada o ascendent). Per exemple, quan es visita una plana web, s’envia a la xarxa la petició (uns pocs bytes) i posteriorment es rep a l’ordinador la pàgina desitjada formada pel text i imatges (el volum dels mateixos depèn del contingut i tipus de la pàgina, però és molt superior al volum de la petició realitzada).

Els serveis incompatibles amb aquest sistema de comunicació poden ser els següents: Fil musical (Encara que existeixen alternatives), TRAC (Telefònica Rural d’Accés Cel·lular), línies de backup, etc.

Una altra característica important de l’ADSL és que separa la veu i les dades tal i com hem comentat anteriorment. Això permet que la línia de telèfon no es vegi afectada en cap sentit a l’hora de rebre i emetre trucades, mentre que al mateix temps es pot estar utilitzant qualsevol servei d’internet subministrat a través d’una línia ADSL (Navegació, Correu electrònic, etc.).

Marc Legal

L’oferta de servei basats amb la tecnologia ADSL a Espanya estan regulats pel ministeri de Foment, amb el doble objectiu, de tractar de satisfer les demandes dels usuaris i afavorir la implantació de noves tecnologies. Per aquest motiu es va publicar a les Ordres Ministerials del dia 26 de març de 1999 (O.M. 8181 i 8182 publicades al BOE 086-1999 de10 d’abril de 1999), que ha passat a ser la pesa bàsica del marc normatiu vigent al sector.

Limitacions Tècniques

La possibilitat d’accedir al servei ADSL dependrà d’unes característiques tècniques concretes de la línia de l’abonat, segons els aspectes següents:

• Que la central telefònica a la que estigui connectada la línia tingui activat el

servei ADSL. Aquesta disponibilitat es pot consultar a partir del numero de telèfon a través del Ministeri de Ciències i Tecnologia.

• Que la qualitat de la línia ho permeti, depenent de la distancia a la central i

de la qualitat del cable telefònic. Només es pot certificar la validesa de la línia telefònica realitzant les oportunes mesures des del domicili de l’usuari final per personal especialitzat, en el moment de la instal·lació.



Avantatges

• Elevat ampla de banda. • Diferents velocitats de connexió en funció de les necessitats de l’usuari. • Tarificació plana durant 24 hores. • No és necessari establir una connexió, ja que es troba sempre connectat. • Deixa lliure la línia telefònica pel servei de veu, utilitzant-se

simultàniament.

1.6.3.2. Fibra Òptica:

La fibra òptica està composada per filaments de vidre d’alta puresa molt compactes. El grossor d’una fibra òptica és com la d’un cabell humà aproximadament. Aquest components es fabriquen a alta temperatura amb base de silici, els seus processos d’elaboració es controlen per mitja de computadores, per permetre que l’índex de refracció del nucli, que és la guia de la ona lluminosa, sigui uniforme i evitar les desviacions.

Característiques:

Com a característiques principals de les fibres òptiques podem destacar que són compactes, lleugeres, amb baixes pèrdues de senyal, àmplia capacitat de transmissió i un alt grau de fiabilitat ja que són immunes a les interferències electromagnètiques de radiofreqüència. Les fibres òptiques no condueixen senyals elèctrics, condueixen rajos lluminosos, per lo tant són idonis per incorporar-se en cables sense cap component conductiu i poden utilitzar-se en condicions perilloses d’alta tensió.

Figura 19. Secció lateral d’una fibra òptica. Tots els rajos incideixen entre R1 i R3 (dintre de l’angle màxim d’acceptació) es propaguen

per la fibra òptica.



Els tipus de Fibra Òptica

a) Fibra multimodal: En aquest tipus de fibra es mouen diferents raigs òptics reflectits a diferents angles. Aquests raigs òptics recorren diferents distancies i es desfasen al viatjar dintre de la fibra. Per aquesta raó, la distancia a la que es pot transmetre està limitada.

b) Fibra multimodal amb índex graduat: En aquest tipus de fibra òptica el

nucli està fet de varies capes concèntriques de material òptic amb diferents índexs de refracció. En aquestes fibres el número de raigs òptics diferents que es mouen és menor i, per lo tant, pateixen menys problemes que les multimodals.

c) Fibra monomodal: Aquesta fibra òptica és la de menor diàmetre i solament

permet viatjar al raig òptic central. No pateix l’efecte de les altres dos però és més difícil de construir i manipular. És també més costosa però permet distancies de transmissió més grans.

Figura 20. Tipus de Fibres Òptiques.



En comparació amb el sistema convencional de cables de coure, on l’atenuació de les senyals és de tal magnitud que requereix de repetidors cada dos quilometres per regenerar la transmissió, en el sistema de fibra òptica es poden instal·lar trams de fins 70 Km sense la necessitat de recórrer a repetidors, el que també el fa més econòmic i de més fàcil manteniment.

Amb un cable de sis fibres es pot transportar el senyal de més de cinc mil canals o línies principals, mentre que es requereixen de 10.000 parells de cables de coure convencionals per brindar serveis al mateix número d’usuaris, amb el desavantatge que aquest últim mitjà ocupa un gran espai en els canals i requereix de grans volums de material, el que també eleva el cost.

Originalment, la fibra òptica va ser proposada com a mitja de transmissió degut a l’enorme ampla de banda, encara que, amb el temps s’ha introduït en un ampli rang d’aplicacions a més a més de la telefonia, automatització industrial, computació, sistemes de televisió per cable, etc.

En un sistema de transmissió per fibra òptica existeix un transmissor que s’encarrega de transformar les ones electromagnètiques en energia òptica o en lluminosa. Per aquest motiu es considera el component actiu d’aquest procés. Quan el senyal lluminós es transmet per les petites fibres òptiques, a l’altre extrem del circuit es troba un tercer component al que es denomina detector òptic o receptor, que té la missió de transformar el senyal lluminós en energia electromagnètica, similar al senyal original. El sistema bàsic de transmissió es compon per aquest ordre, de senyal d’entrada, amplificador, font de llum, corrector òptic, línia de fibra òptica (primer tram), entroncament, línia de fibra òptica (segon tram), corrector òptic, receptor, amplificador i senyals de sortida.

Es pot dir que en aquest procés de comunicació, la fibra òptica funciona com a mitja de transport de senyal lluminosa, generada per transmissors de LED’s i làsers.

Els díodes emissors de llum i els díodes làsers són fonts adequades per la transmissió mitjançant fibra òptica, degut a que el seu senyal es pot controlar ràpidament per mitja d’un corrent de polarització. A més a més, el seu volum, la lluminositat, longitud d’ona i el baix voltatge necessari per utilitzar-ho són característiques atractives.



Avantatges i Desavantatges

Avantatges

La fibra òptica presenta un gran ample de banda, el que suposa més informació per conductor que amb els mitjans convencionals. Els valors van des dels centenars de MHz fins a desenes de GHz.

L’atenuació que presenta és independent de la velocitat de transmissió a la que s’explota, el que no passa en els cables convencionals. Per l’altra part, presenta certes atenuacions, funció de les seves característiques físiques, que a més a més són variables amb la longitud d’ona del senyal que la travessa. Aquesta atenuació passa per uns mínims en determinades longituds d’ona.

La fibra òptica és immune al soroll i a les interferències per ser un mitjà dielèctric, característica positiva en moltes aplicacions, sobre tot quan el cable ha de passar per zones d’alta tensió.

La informació que viatge per la fibra no es pot detectar, perquè la llum no és sensible a cap fenomen de tipus inductiu per l’especial configuració del seu camp electromagnètic. Això explica que prop del 10% de la producció mundial de fibra es destini a instal·lacions militars.

La fibra òptica presenta dimensions més reduïdes que mitjans preexistents, el que es tradueix en economia de transport. Un cable de 10 fibres té un diàmetre aproximat de 8 o 10 mm i proporciona la mateixa o més informació que un cable coaxial de 10 tubs.

El pes del cable de fibra òptica és molt inferior al dels cables metàl·lics.

La fibra òptica presenta un funcionament uniforme des de –55ºC a + 125ºC sense degradació de les seves característiques, al contrari del que passa amb molts cables metàl·lics, que la seva atenuació depèn de la seva resistència i aquesta depèn de la temperatura.

La matèria primera per fabricar la fibra òptica és abundant a la natura, el que porta el cost a la baixa segons milloren els processos d’elaboració, al contrari del que passa amb el coure, que el seu preu depèn fonamentalment de les reserves.



Desavantatges

Pot resultar més car si les seves avantatges no són correctament avaluades.

Les pèrdues d’acoblament i les seves dificultats en aplicacions de camps pel petit diàmetre de les fibres òptiques.

Algunes fonts lluminoses tenen una vida útil molt limitada, com per exemple el Làser.

Signat:

Pere Ferrer Casaoliva Setembre 2004


Memòria de Càlcul

2. Memòria de Càlcul

Índex Índex.................................................................................................................. 1 2. Memòria de Càlcul ................................................................................... 2

2.1. Projecte Realitzat................................................................................................... 2 2.1.1. Client ................................................................................................................. 2 2.1.2. El Projecte ......................................................................................................... 2

2.2. Nocions prèvies ..................................................................................................... 3 2.2.1. Operacions amb Targetes.................................................................................. 3 2.2.2. Reclamacions..................................................................................................... 4 2.2.3. Conceptes d’Intercanvi...................................................................................... 5 2.2.4. Sentit dels Moviments ........................................................................................ 5 2.2.5. Tipus de Targetes .............................................................................................. 6 2.2.6. Centre Autoritzador........................................................................................... 7 2.2.7. Alta de Contracte i Targetes.............................................................................. 8 2.2.8. Facturació de Targetes de Dèbit. ...................................................................... 9 2.2.9. Facturació de Targetes de Crèdit.................................................................... 10 2.2.10. Alta de Comerços ........................................................................................ 10 2.2.11. Autorització d’Operacions .......................................................................... 10 2.2.12. Liquidació de la Facturació a Comerços.................................................... 11

2.3. Eines Utilitzades .................................................................................................. 12 2.3.1. El Programari Utilitzat ................................................................................... 12 2.3.2. La Programació............................................................................................... 13 2.3.3. Les Eines CASE ............................................................................................... 14 2.3.4. On-Line............................................................................................................ 15 2.3.5. Creació de Pantalles ....................................................................................... 15 2.3.6. Normes de Disseny Extern............................................................................... 17 2.3.7. Disseny de Transaccions STO ......................................................................... 24 2.3.8. Les Bases de Dades ......................................................................................... 26

2.4. Bases de Dades Utilitzades.................................................................................. 27 2.4.1. APLB01Z. Incidències de Targetes: ................................................................ 28

2.4.1.1. APLS010. Expedients d’Incidències ....................................................... 28 2.4.1.2. APLS011. Succés d’un Expedient........................................................... 32 2.4.1.3. APLS012: Dades Captura de l’Operació................................................. 36 2.4.1.4. APLS013: Comentaris............................................................................. 36

2.4.2. APLB02Z: Base de Dades de Targetes amb Incidències ................................ 36 2.4.2.1. APLS020: Targetes ................................................................................. 36 2.4.2.2. APLS021: Expedients d’una Targeta ...................................................... 37

2.4.3. APLB03Z: Base de Dades amb les Dades Mestres de les Targetes................ 37 2.5. Projecte Realitzat a l’Empresa............................................................................. 38

2.5.1. Introducció ...................................................................................................... 38 2.5.2. Generació de Pantalles ................................................................................... 39 2.5.3. Disseny ............................................................................................................ 40 2.5.4. Implementació ................................................................................................. 40

2.5.4.1. Entorn de Treball ..................................................................................... 40 2.5.4.2. Codi del Programa................................................................................... 41

2.5.5. Problemes Durant el Projecte ......................................................................... 44

Memòria de Càlcul 1



2.1. Projecte Realitzat

Abans d’entrar a valorar quina ha estat la meva aportació a aquest projecte, explicarem per a qui és el projecte i quina és la seva finalitat.

2.1.1. Client

El projecte que s’ha realitzat i que aquí explicarem, s’ha desenvolupat per una important entitat financera del nostre país. Getronics s’encarrega del manteniment d’una gran part de la seves infrastructures i realitza una part molt important dels seus nous projectes. Aquesta entitat disposa del seu propi servei de producció, però és molt freqüent que subcontracti la producció de nous projectes a empreses externes.

L’estructura informàtica del client es troba dividida en diferents aplicacions, i per tal de donar un bon servei, Getronics organitza els seus equips de treball de la mateixa manera. Aquests aplicatius s’originen a partir de les diferents àrees de negoci de l’entitat i encara que són independents sempre existeix una forta relació entre ells ja que solen compartir molta informació.

2.1.2. El Projecte

El projecte es troba orientat cap el tractament d’incidències de targetes. És a dir, totes aquelles operacions errònies que es produeixen quan es realitza un pagament amb targeta. Un exemple, podria ser la compra d’uns pantalons per un import de 20 euros i el càrrec que ens arribés fos de 30 euros. Si ens trobéssim en aquesta situació ens dirigirem a la nostra entitat per iniciar una reclamació perquè ens retornin els 10 euros de diferència.

Internament l’entitat bancària inicia una sèrie de moviments, que ara no entrarem a detallar, per tal de resoldre el problema.

En aquest moment el nostre client ja disposa d’una operativa que gestiona tots aquest moviments de targeta. L’objectiu del nou projecte és generar una nova operativa On-Line exclusivament pels serveis centrals de l’entitat financera que els permeti gestionar de manera més eficient totes les incidències de targetes que es produeixen.



Els objectius de la nova operativa On-Line seran els següents:

• Crear operacions noves pel control de les incidències de les targetes:

Sol·licitud de documentació d’operacions amb targeta. Nova consulta d’incidències que integri tota l’informació necessària de

manera compacta per cada tipus d’incidència concreta de manera que faciliti el posterior tractament de la mateixa.

Traspàs de les incidències a les oficines. Resolució contra ingressos i despeses d’una incidència. Resolució contra pèrdues i guanys d’una incidència. Anul·lació de Traspàs. Anul·lació de resolució contra ingressos i despeses . Anul·lació de resolució contra pèrdues i guanys.

• Incorporar a les bases de dades noves dades referents a les incidències i a les operacions relacionades amb elles per una major comprensió i gestió de les mateixes.

• Portar a terme modificacions comptables respecte a l’operativa existent a les

resolucions contra entitats.

• Crear informació estadística de les resolucions realitzades a través d’un llistat de periodicitat mensual.

2.2. Nocions prèvies

En aquest apartat s’explicarà una sèrie de conceptes que facilitaran la comprensió posterior de l’operativa.

2.2.1. Operacions amb Targetes

Són totes aquelles operacions que s’hagin fet amb una targeta. Per cada operació que es realitza amb una targeta, es genera un moviment que es considera comptable al tenir afectació directa sobre el compte del client o sobre l’extracte de la targeta. És a dir, són tots aquells moviments que tenen una afectació econòmica sobre el compte del titular (targetes de dèbit) o l’extracte de la targeta (targetes de crèdit).



Bàsicament en la nostra aplicació ens trobarem amb els següents tipus d’operacions:

• Factures: Per factura entenem la compra que efectua el client en un comerç amb la seva targeta.

• Devolucions: Entenem per devolució quan es retorna la compra. És a dir, quan

el client ha realitzat una compra i retorna el producte. El comerç pot no retornar els diners en efectiu i pot optar per un moviment de devolució. Aquest moviment de devolució es realitza al compte del titular quan es tracta d’una targeta de dèbit o a l’extracte de la targeta quan és de crèdit.

• Bestreta: Per bestreta entenem els moviments de disposició d’efectiu per part

del client. Bàsicament són operacions de retirada d’efectiu realitzades als caixers automàtics. Aquest tipus d’operacions poden ser a dèbit o a crèdit (Només amb targetes de crèdit).

2.2.2. Reclamacions

Per reclamacions entenem aquelles accions inicials contra operacions sobre les que s’ha detectat alguna incidència.

Bàsicament en la nostra aplicació ens podem trobar amb els següents tipus d’operacions:

• Fotocòpies: Quan el titular observa alguna incidència entre les operacions de la seva targeta, l’entitat emissora (Entitat emissora de la targeta) pot sol·licitar a l’entitat adquirent (Entitat propietària del Terminal Punt de Venda) una fotocopia del rebut signat pel seu client.

• Retrocessions: Per retrocessió entenem l’operació contrària a l’operació

reclamada. Ens podem trobar amb retrocessions de factures, devolució o bestreta. Per exemple, un retrocessió de factura seria retornar els diners del moviment al titular de la targeta.



2.2.3. Conceptes d’Intercanvi

Per que quedin més clars alguns dels conceptes mencionats anteriorment, a continuació els definirem.

• Entitat Emissora: Per entitat emissora entenem l’entitat que gestiona la targeta i es propietària d’aquesta.

• Entitat Adquirent: Per entitat adquirent entenem l’entitat propietària del TPV

(Terminal Punt de Venda), es a dir l’entitat que gestiona els moviments que es realitzen al comerç.

• Tipus d’Intercanvi: Per tipus d’intercanvi entenem les diferents vies que

poden seguir les operacions. Per exemple, quan un titular d’una targeta Visa opera amb aquesta a l’estranger, el tipus d’intercanvi serà Visa Internacional.

• Tipus d’Operació: Per tipus d’operació entenem el tipus de moviment que

estem rebent o enviat a intercanvi. Per exemple, una retrocessió de factura, una petició de fotocopia, etc.

• Motiu d’Intercanvi: Per motiu d’intercanvi entenem el motiu pel qual es

realitza la reclamació. Per exemple, una operació duplicada, una operació que no pertany al client, etc.

• Bank Identification Number (BIN): És el número d’identificació d’una

targeta, està composat per 6 dígits i aporta informació sobre la entitat financera a la que pertany.

• Referència d’Intercanvi: Es tracta d’un identificador únic de l’operació.

Dintre d’aquest codi podem trobar el BIN de la referència, que es correspon amb un BIN propietat de l’entitat adquirent.

2.2.4. Sentit dels Moviments

Segons l’origen del moviment els podem dividir en els següents punts:

• Moviment Incoming: És un moviment que té com origen una entitat diferent a la nostra i com a destí la nostra entitat.



• Moviment Outgoing: És un moviment que té com origen la nostra entitat i com a destí una altra entitat diferent.

• Moviment ON-US: És un moviment que té com origen i destí la mateixa

entitat.

2.2.5. Tipus de Targetes

Es pretén realitzar una classificació de les targetes que es poden trobar en l’actualitat al mercat:

• Targeta de Crèdit: Proporciona crèdit immediat que es pot utilitzar tant per pagar a un establiment, obtenir diners en efectiu, etc. Els diners que disposen aquestes targetes ve limitat pel crèdit aprovat per l’entitat emissora. Com exemple de targetes de crèdit tenim la VISA Clàssic o l’American Express.

• Targetes de Dèbit: El pagament es realitza contra un compte corrent o llibreta

d’estalvi a traves dels TPV’s, el que comporta disposar de saldo efectiu o descobert autoritzat per l’entitat.

• Targeta Moneder: Targetes destinades al pagament de petites fraccions de

diners. Es poden recarregar en els propis caixers automàtics a qualsevol hora, sense necessitat de desplaçar-se a l’entitat financera. Aquest tipus de targetes estan en desús ja que no ha tingut una bona acceptació per part dels usuaris.

• Targeta Integrals: Targetes que incorporen varies funcions.



2.2.6. Centre Autoritzador

La gran majoria d’operacions realitzades amb targetes necessiten autorització. A Espanya s’han configurat, històricament, dos models diferents de “Centre Autoritzador”:

• Sistema 4B: Les entitats financeres no gestionen directament els TPV’s i ATM’s (Caixers Automàtics), sinó que és el Sistema 4B qui dona el servei a les entitats. En aquest model, els equips (TPV’s o ATM’s) estan connectats al node de 4B. Les autoritzacions del propi sistema són encaminades als centres autoritzadors de les entitats corresponents, o resoltes en Back-Up. Les targetes alienes que operen en el seu entorn són connectades cap els nodes corresponents.

• SERMEPA i CECA: El sistemes de SERMEPA (Servei per a Mitjans de

Pagament) i CECA (Confederació Espanyola de Caixes d’Estalvi) permeten a les entitats financeres treballar amb un centre d’autorització mixt. Això significa que les pròpies entitats poden tenir el seu propi centre autoritzador, des d’on gestionen els seus TPV’s i ATM’s, així com la resolució de les autoritzacions de les seves pròpies targetes. Tot i això, si l’entitat ho sol·licita poden actuar com s’ha descrit en el model anterior.

Figura 1. Esquema Centres Autoritzadors

TPV

4B

TPV TPV

ATM CECA ATM SERMEPA

Entitat Entitat

TPV ATM

ATM

ATM TPV



Cada entitat financera esta connectada directament amb un centre autoritzador i aquest esta connectat als tres nodes centrals (centres autoritzadors). A la seva vegada cada node esta connectat amb Visa Internacional, Master Internacional, etc.

Al realitzar una operació, ja sigui en un TPV o en un ATM, es realitza una comunicació amb l’entitat adquirent. Una vegada realitzada la connexió es busca l’entitat emissora de la targeta que realitza l’operació per poder autoritzar-la. La xarxa funciona com un arbre, on es consulta el centre autoritzador superior fins trobar la entitat emissora.

2.2.7. Alta de Contracte i Targetes

L’alta d’una targeta de dèbit no comporta riscos, ja que el pagament es fa efectiu immediatament, passant per un centre autoritzador. Per aquest motiu és senzill que una entitat financera ofereixi als seus clients aquest tipus de targetes. En canvi, una targeta de crèdit comporta un risc, per aquest motiu es realitza un anàlisis dels comptes i els ingressos del client.

Un model seguit per un nombre important d’entitats a l’hora de donar d’alta una targeta de crèdit es basa, per aquelles targetes amb domiciliació del pagament a la pròpia entitat, en:

• Un compte disponible en el qual es realitzaran els pagaments amb la periodicitat que es determina.

• Un contracte de targetes, associat al compte. El titular del contracte ha de ser

titular també del compte. En el contracte podran figurar altres persones físiques que no forçosament tinguin que ser titulars del compte o de l’entitat.



Pel contracte, si s’han assignat targetes de crèdit (incloses affintys), s’han d’establir els següents conceptes:

• Límits de crèdit. En funció de l’import sol·licitat podria quedar en situació de pendent d’aprovació per un centre superior. Però, normalment, el límit de crèdit serà únic per totes les targetes del contracte.

• Instruccions de reemborsament. Utilitzarem conceptes com dèbit/crèdit,

pagament mensual/setmanal, pagament total o parcial, etc.

• Instruccions temporals de límit de crèdit o de reemborsament, si fos el cas.

• Bonificacions del contracte, etc.

Tant pel contracte com per la targeta han d’existir opcions de modificació que permetin ajustar d’una manera dinàmica (mitjançant l’On-Line de l’aplicació) les necessitats del client.

2.2.8. Facturació de Targetes de Dèbit.

No sempre s’efectua el pagament al realitzar l’operació, això depèn del tipus de TPV. En entorns Off-Line, on la validació no és directa, no s’imputen les operacions en el moment de la seva realització, sinó s’espera a la seva presentació (normalment per la nit).

Si operem a dèbit estem realitzant un carrega al compte del client i estem gravant un moviment a les taules d’operacions corresponents, perquè posteriorment aparegui al consultar les operacions de la targeta. Normalment es guarden totes les operacions iniciades en TPV’s, d’aquesta manera es facilita la resolució de possibles incidències.

Si l’entorn es ON-US (Comerç i Targeta propis) l’imputació es pot realitzar immediatament.

A l’inicialitzar una operació des d’un TPV trobem dos possibles tipus d’execució:

• Missatge Doble: En un primer moment s’envia la sol·licitud d’autorització, per

part de l’entitat adquirent. Quan es rep l’autorització s’envia el missatge comptable amb la liquidació.

• Missatge Comptable o Únic: S’envia la sol·licitud d’autorització junt amb la

liquidació comptable (es paga a l’adquirent i es carrega a l’emissor de la targeta) i no requereix d’un segon enviament per la liquidació.



2.2.9. Facturació de Targetes de Crèdit

La facturació a crèdit no s’imputa al compte del client en el moment de la seva recepció si no que queda contemplada dins de l’extracte de la targeta on es van acumulant les diferents operacions que realitza el titular. Aquestes operacions es guarden a les taules corresponents amb el màxim d’informació possible per poder facilitar la seva identificació en el cas de retrocedir l’operació.

Els circuits d’autorització i liquidació són els descrits anteriorment per les targetes de dèbit. Tant CECA com SERMEPA estan propiciant el missatge únic conforme s’ha descrit anteriorment. En aquest cas les operacions que s’hagin autoritzat passen a formar part de les operacions pendents d’imputar al titular i incrementa el límit disposat del contracte de la targeta. Mensualment (o setmanalment) les entitats tanquen l’extracte de les operacions pendents i envien l’informació al titular.

2.2.10. Alta de Comerços

A l’igual que es firma un contracte amb els titulars de les targetes també es requereix al donar d’alta un comerç. En el contracte amb el comerç es troben les condicions econòmiques (descompte comercial que s’aplica, període dels abonaments, etc.). Així com les comissions pel lloguer i manteniment del TPV.

L’alta dels comerços ha de ser comunicada als sistemes de targetes (Sistema 4B si pertany a ell, a CECA les Caixes d’Estalvis i a SERMEPA les entitats que estiguin adherides). En l’alta del comerç es mostra l’identificació del comerç i el “Sector d’activitat” en el qual es troba l’activitat principal del comerç.

2.2.11. Autorització d’Operacions

A continuació tenim els punts bàsics que s’han de donar per sol·licitar l’autorització d’una operació de venda pagada amb targeta.

Des del punt de vista del comerç:

• Comprovació de la validesa de la targeta. Existència del logotip de la targeta

(Visa, 6000, 4B, ...), que no presenta modificacions, holograma de seguretat, identitat del titular, etc.



• Passar la targeta pel lector de bandes magnètiques del TPV, teclejar l’import i sol·licitar el PIN (si fos necessari).

• Transmetre l’operació al seu centre d’autoritzacions.

• Si la resposta és d’acceptació, verificar que les dades impreses al comprovant

(número de targeta, nom i caducitat) coincideixen amb els que figuren a la targeta.

• Sol·licitar al titular de la targeta que signi el comprovant i validar les signatures

del comprovant i la targeta.

• Donar una copia de la boleta al titular. El comerç haurà de conservar, a disposició de la seva entitat financera, l’original que ha signat el titular de la targeta durant un any.

El centre de autoritzacions ha de:

• Verificar el TPV i el comerç.

• Si la targeta es pròpia, encaminarà la transacció internament. Si la targeta es

aliena, encaminarà la transacció cap el node corresponent.

• Controlar la resposta i facilitar-la al TPV/Comerç. L’absència de resposta ha de ser comunicada també al TPV/Comerç, i originar l’anul·lació automàtica de la mateixa cap a l’entorn que correspon (intern o extern) per tal de desfer l’operació inicial.

• Guardar l’informació de les operacions autoritzades per permetre la seva

posterior liquidació als comerços.

2.2.12. Liquidació de la Facturació a Comerços

Normalment les operacions que han processat els TPV’s es liquiden de manera centralitzada per l’entitat financera. A partir de l’informació capturada pel centre d’autoritzacions durant el dia es genera un procés mitjançant el qual es creen les remeses corresponents per cada comerç que hagi operat i es generen els abonaments als comptes.



L’abonament generat al comerç serà igual a la suma dels pagaments realitzats menys els descomptes aplicats al comerç. Per cada operació es paga un tant per cent de comissió. Depenent del tipus de comerç (Ram del comerç) s’estableix el tant per cent de comissió. Sobre aquest valor un 85% es la comissió que cobra l’entitat emissora de la targeta i el 15% és el valor que es queda l’entitat adquirent.

El comerç rep una copia de la remesa corresponent als abonaments realitzats al compte. Aquesta copia mostra el detall de les operacions processades i els descomptes aplicats.

2.3. Eines Utilitzades

El projecte es desenvolupa dins de l’entorn Host del client. Això significa que sempre s’ha treballat amb un emulador de terminal connectat a aquest Host.

L’entorn consisteix en una màquina IBM amb un sistema operatiu MVS (Multiple Virtual Storage), situat a l’oficina central del client, i en una sèrie d’eines per facilitar el desenvolupament, les proves, el funcionament i el manteniment dels programes.

Podem diferenciar dos tipus de programació, una del tipus Batch, que s’encarrega de realitzar processos d’actualització de bases de dades i generació de fitxer. I una programació del tipus On-Line, encarregada de generar els diferents menús de consulta o actualització utilitzats directament pels treballadors de les entitats financeres.

2.3.1. El Programari Utilitzat

Dins del programari utilitzat pel desenvolupament de projectes, podem diferenciar entre el propi del client (creat específicament pel client) i el que no és propi. En el primer grup podem destacar una eina CASE (Computer Aided Software Engineering) dissenyada per la gestió de l’On-Line, algunes eines de treball i tota la bibliografia de components reutilitzables de codi (agrupats en macros i mòduls). Entre el software extern destacar el sistema operatiu, les eines de desenvolupament, les eines de disseny i l’entorn de treball.

El sistema operatiu és el MVS i ens proporciona serveis d’alt nivell. Aquest sistema utilitza dos eines fundamentals: TSO i IMS:

• TSO (Time Shared Option) permet la connexió simultània de varis terminals al

Host principal i té utilitats de desenvolupament tals com l’editor, l’entorn de programació (escriptori), el compilador, la visualització de les cues de sortida dels processos Batch, el planificador de processos Batch, etc.

• IMS (Information Management System) és un altra servei d’alt nivell sobre el

que funciona l’On-Line i té capacitats d’accés a bases de dades.



2.3.2. La Programació

El llenguatge de programació utilitzat és PL/I. Existeixen dos entorns on conviu el software creat:

• Entorn de Desenvolupament: En aquest entorn es genera el nou software i es

realitzen les proves necessàries. En aquest entorn les dades guardades únicament s’utilitzen per fer proves i no són reals.

• Entorn d’Explotació: Una vegada el projecte s’ha finalitzat i s’ha provat

exhaustivament, s’instal·la en aquest entorn on el client pot utilitzar els programes creats. Les bases de dades que trobem en aquest entorn guarden dades reals dels clients.

Cada entorn té un codi diferent, dades pròpies i treballa en diferents CPU’s (Hosts). Per poder operar amb dades reals (també conegudes com dades de públic), es necessita tenir permís del client. L’entorn d’explotació té limitat el nombre simultani d’usuaris que poden estar connectats per evitar la sobreexplotació dels recursos del sistema que el client està utilitzant per operar.

Per poder treballar a l’entorn de proves dos persones simultàniament sobre el mateix component tenim un sistema de control de versions. El funcionament és el següent, es declara una versió amb tots els components necessaris per realitzar el projecte (programes, mòduls, includes, compilacions, etc.). Ens podem trobar que algun dels components ja es troben en una altra versió i s’estan modificant per un altre usuari. A l’esta en dos versions diferents no tindrem cap problema l’un sobre l’altre ja que són independents i les modificacions d’un no afecten a l’altre.

Existeixen unes normes de programació estrictes per part del client respecte la claredat del codi font, rendiment dels programes, qualitat del software, etc. Per aquest motius existeixen una sèrie d’eines d’obligada utilització per tal de detectar possibles errors.

Cal destacar dos d’aquestes eines:

• QUALITAT: Realitza una compilació del programa amb la finalitat de detectar el rendiment de les sentències DB2 (Universal Data Base), si existeixen funcions que no es criden, si el codi no està suficientment comentat, etc.

• SINTAXIS: Realitza una validació sintàctica del codi sense generar

l’executable. D’aquesta manera es poden detectar errors de codi estalviant els recursos d’una compilació típica.



La finalitat de tot és que el codi sigui intel·ligible per qualsevol membre de l’aplicació i tingui un alt rendiment. Això és de vital importància pel manteniment de l’aplicació, ja que no sempre realitzarà les modificacions del programa la mateixa persona.

Un factor important en el desenvolupament del software es la reutilització del codi. El client disposa d’una amplia biblioteca de codi reutilitzable i d’eines de consulta. Durant la fase de programació s’utilitzen moltes macros i es criden a mòduls ja programats que implementen funcionalitats varies com pot ser escriure les capçaleres d’un programa Batch, tractar fitxers, accedir a bases de dades, calcular o modificar el format de la data, validar si un camp és numèric, etc. Com més macros s’utilitzen en un programa, millor intel·ligibilitat.

També es reutilitzen els missatges d’error que es donen a l’usuari. Existeix una base de dades amb tots els missatges d’error utilitzats fins al moment i que serveixen per a la majoria de situacions amb el que un es pot trobar al programar. En aquesta base de dades existeixen llistes amb errors estàndards per a totes les aplicacions i amb errors específics per a cada aplicació.

2.3.3. Les Eines CASE

El client disposa d’una versió feta a mida d’una coneguda eina CASE. Aquesta aplicació centralitza tot el disseny i l’inventari de les aplicacions que es creen.

Tots els components (mòduls, programes, estructures de dades, taules de bases de dades, ets.) es defineixen primer en aquesta eina, d’aquesta manera s’informa al diccionari del Host dels nous components. El diccionari del Host conté tot l’inventari de components de software que té el client.

En el cas particular de les aplicacions On-Line, també s’utilitza per crear les pantalles i els seus formats. Es defineixen les transaccions, que ens permeten enllaçar les pantalles amb el codi corresponent.



2.3.4. On-Line

La programació On-Line genera pantalles i transaccions que accedeixen a les dades i realitzen les operacions corresponents sobre les bases de dades. Les pantalles estan estructurades de forma jeràrquica, es a dir, s’ha de seguir una seqüència de pantalles depenent de l’operació a realitzar.

La programació d’aplicacions On-Line es diferència clarament de la programació Batch per tenir una estructura especial. Es defineixen una sèrie de macros i mòduls dissenyats pel propi client per facilitar la programació.

S’han de diferenciar dos tipus de terminals financers. En primer lloc tenim el Terminal 3270, definit a l’entorn IMS del sistema, per tal de poder realitzar proves del projecte mentre es programa. També tenim el Terminal Financer que s’utilitza a les oficines de les entitats financeres. Abans de traspassar el projecte a l’entorn d’explotació s’han de realitzar proves amb aquest terminal, per assegurar que l’usuari final no tingui problemes amb el projecte.

Les pantalles es defineixen a partir de l’eina CASE comentada i s’associen a una transacció. Per conèixer millor el funcionament s’ha d’estudiar l’arquitectura On-Line que ens proporciona el Host. El sistema utilitzat, s’engloba dins un marc general per desenvolupar transaccions caracteritzades per seguir una arquitectura orientada a objectes.

2.3.5. Creació de Pantalles

Al crear les pantalles s’ha de tenir en compte les necessitats del client. L’aprenentatge de l’usuari final ha de ser senzill i el més ràpid possible, pel que es manté sempre la mateixa estructura de pantalles. Per aquest motiu es defineixen unes normes de disseny externes comunes per a totes les aplicacions.

Dintre del sistema informàtic és absolutament imprescindible que la interfície d’usuari sigui optimitzada cap a la facilitat d’us i provoqui autoaprenentatge de cara a l’usuari final. Quan els marcs d’actuació, les tècniques d’interacció i la terminologia utilitzada són consistents, els usuaris desenvolupen un model conceptual de com s’ha de treballar al sistema. A l’introduir noves accions que respecten el model conceptual l’aprenentatge de l’usuari és molt més ràpid.



El model conceptual creat per l’usuari es totalment independent al model de integració física. L’usuari no coneix com es realitzen les operacions, resol accions (no transaccions), com s’han realitzat les operacions ha de ser totalment transparent a l’usuari.

El sistema de pantalles es presenta en forma d’arbre on la primera pantalla és el menú principal de l’aplicació. A partir d’aquesta pantalla s’accedeix a menús més específics o a pantalles d’acció.

Depenent de la funcionalitat de cada pantalla es defineixen diferents tipus:

• Menú de Selecció d’Objectes: Mostra un menú de diferents objectes sobre els

que es realitza una acció.

• Menú per Seleccionar Accions: Mostra les diferents accions que podem fer sobre un objecte.

• Llista d’Objectes: Proporciona un llistat d’objectes, amb alguna característica

comú i amb la possibilitat de realitzar accions específiques sobre cada objecte.

• Pantalla Genèrica de Treball: Mostra camps d’entrada/sortida. Permet realitzar consultes o gestionar dades.

• Final de Diàleg: Indica que l’operació ha finalitzat.

Cada tipus de pantalla tindrà un disseny específic, d’aquesta manera es facilita al màxim el treball de l’usuari. Seguint les normes de disseny extern s’assegura la consistència entre totes les pantalles del sistema.



2.3.6. Normes de Disseny Extern

El disseny extern de l’aplicació es basa en la declaració de les pantalles, aquest és l’únic punt on l’usuari pot interactuar amb el sistema informàtic. S’estableixen unes normes de disseny de les pantalles per facilitar l’adaptació de l’usuari.

Les pantalles tenen 24 files per 80 columnes, estructurades en un conjunt de zones segons el tipus d’informació a mostrar. Cada tipus de pantalla inclou unes zones concretes, no és obligatori definir totes les zones a totes les pantalles.

Capçalera

Menú de Selecció de Literals

Camps d’Entrada

Zona

de

Treb

all

Accions per llistes d’Objectes / Llistes d’Objectes

Missatges del Programa / Accions Addicionals

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

Missatges del Sistema / Tecles de Funció

1 2 3 4 5 6 7 8 9 101112131415161718192021222324

Figura 2. Estructura Pantalla Estàndard



Al desenvolupar una aplicació, l’eina editora de pantalles limita la pantalla a 24 files per 80 columnes. El Terminal Financer es capaç de mostrar 25 files per 80 columnes. Per aquest motiu, a l’edita pantalles es solapen dos tipus de continguts diferents a la línia 24 (missatges de sistema i tecles de funció). El Terminal Financer s’encarrega de distribuir aquestes dades, mostrant el missatge de sistema a la línia 24 i les tecles de funció a la línia 25.

Atributs disponibles

Per cada element que apareix a la pantalla es defineixen uns atributs, que indiquen l’aspecte que tindrà cada element a la pantalla. Actualment es defineixen els següents atributs:

• Protegit / No Protegit • Normal / Brillant / No Visible • Normal / Subratllat / Invers / Parpelleig

Per cada una de les series d’atributs, els conceptes són mútuament excloents. Tampoc existeix la combinació Brillant - Invers.

Zona de la Capçalera

Aquesta zona es obligatòria per totes les pantalles del sistema. Ocupen les línies 1 i 2 de la pantalla, les dues línies protegides i amb aspecte invers. Conté dades d’identificació bàsiques de la pantalla, que se situen en una línia i columna concreta.

La primera línia conté la següent informació:

• Logotip de l’Empresa: S’indica el nom de l’entitat on s’executa la pantalla.

• Títol de l’Aplicació: En el centre de la línia s’introdueix el nom de l’aplicació.

• Identificador de la Pantalla: Cada pantalla s’identifica de manera única i

indica des d’on s’inicialitza la transacció. Té el format AAAnnnn, on AAA identifica la aplicació i nnnn és un número que identifica cada pantalla dintre de l’aplicació.



La segona línia de la capçalera conté les següents dades:

• Camp TEROFEM: Camp format pel número de terminal, el centre on s’executa la pantalla i l’empleat que l’executa.

• Títol de la Pantalla: Es troba centrat a la pantalla i ens mostra el títol específic,

normalment representa l’acció que realitza la pantalla. Conté l’encadenament d’opcions que porten a la pantalla des del menú principal de l’aplicació.

• Data Actual: Es mostra la data en que s’executa la pantalla en el format

DD-MM-AA.

• Hora Actual: Indica l’hora amb el format HH:MM

Zona de treball:

És un zona obligatòria per totes les pantalles, però depenent del tipus de pantalla es defineix únicament una de les següents subzones:

• Subzona de Menú de Selecció de Literals: Estructura de literals seleccionables que únicament apareixen a les pantalles de tipus menú. Ocupa la part superior de la zona de treball.

• Subzona de Camps d’Entrada i Sortida: Està formada per literals i camps

d’entrada i sortida. Dintre d’una pantalla es situa a continuació de la subzona de menús.

• Subzona d’Accions per una Llista d’Objectes: Es defineixen les accions que

es poden realitzar sobre els objectes.



Per norma general, cada literal de pantalla s’escriu amb majúscules la primera lletra de la primera paraula. La resta de caràcters s’escriuen en minúscula.

Un literal d’un camp s’utilitza per descriure el camp d’entrada/sortida d’informació. Ha de ser explicatiu però sense omplir excessivament la pantalla. Com a norma general s’escriu en majúscula la primera lletra i la resta en minúscula. Sempre s’acaba amb un blanc i dos punts, mai amb un punt i després l’espai. Si tenim varis camps d’entrada/sortida en forma de columna a la pantalla, farem coincidir els dos punts de cada literal de camp.

Tenim tres tipus de literals de camp, depenent del camp associat: • Literal de Camp d’Entrada. • Literal de Camp d’Entrada Obligatori. • Literal de Camp de Sortida.

Els atributs de visualització dels tres tipus han de ser protegits i amb brillantor normal.

Un literal lliure es aquell que no s’associa a cap camp. S’utilitzen per facilitar la comprensió de la pantalla. Els atributs de visualització han de ser protegits i amb brillantor normal.

El literal descriptiu d’un valor ens mostra el valor discret que pot tenir una dada, es mostra amb els atributs de visualització protegits i amb brillantor normal. Aquest tipus de literal solament s’inclouen si:

• S’estalvien accessos a les ajudes. • S’entenen clarament. • No comporta confusions. • Es mostren tots els valors possibles de la dada.

En el cas de tenir llistats s’han de crear literals per indicar el valor que tenim en cada columna del llistat, això són els literals de capçalera de taules. Tenim d’evitar definir un únic literal amb els camps. Això és molt important per poder traduir la pantalla a un altra idioma, ja que si tenim diferents longituds la pantalla queda desalineada.



Els camps de sortida de dades es tracten com literals variables. El valor del camp es defineix per programa. Els atributs de visualització han de ser protegits, brillants i subratllats. Per últim tenim els camps d’entrada de dades que permeten a l’usuari introduir dades, aquests són els únics camps que es defineixen com no protegits. Se situen a la dreta del literal que els identifica, deixant un espai entre els dos punts del literal. Els atributs de visualització són brillants i subratllats. Si el camp és obligatori s’ha d’indicar en els atributs.

Al distribuir les dades a la pantalla s’intenta agrupar-les segons el tipus. Primer col·locant els camps d’entrada obligatoris, després els d’entrada i per últim els de sortida.

En el cas de tenir un menú, s’introduirà la subzona de menú especifica per aquesta pantalla. Definim una estructura de literals seleccionables on s’indiquen les diferents opcions del menú i el codi de selecció. Sota les opcions, donem la possibilitat de informar el número d’opció.

Si es desitja introduir l’objecte sobre el que es realitza l’acció es defineix sota el menú la subzona de treball, on introduirem els camps d’entrada junt amb els seus literals. Es té que evitar la barreja de menús d’accions i de selecció d’objectes.

L’estructura general d’un llistat es basa en la subzona de treball i a continuació la subzona del llistat. Primer es mostra un literal amb les possibles accions a realitzar sobre els elements de la llista. A continuació tenim el títol de les columnes de les llistes. I per últim introduïm els camps de cada columna. La columna situada més a l’esquerra és un camp d’entrada i s’utilitza per introduir l’acció a realitzar sobre l’element (normalment ocupa una posició).

Es defineixen de manera genèrica les següents accions:

A – Alta. C – Consulta. B – Baixa. M – Modificació. P – Imprimir. R – Retrocedir. X – Selecció.



Zona de Missatges de Programa

Es la zona on es mostren els missatges dirigits a l’usuari. Els missatges de programa poden indicar errors (errors per dades d’entrada incorrectes o errors interns del programa), demanar confirmació a l’usuari per poder realitzar l’acció o indicar el final de l’acció.

Com a mínim ocupa una línia on s’indica el missatge. A la part esquerra sempre té una fletxa intermitent, per què l’usuari s’adoni de l’aparició del missatge.

Si el missatge és d’error haurà d’indicar clarament el tipus d’error produït. També es modificarà l’atribut del camp erroni per ressaltar l’error. D’aquesta manera l’usuari li és més senzill localitzar l’error.

Si el missatge que es mostra és de confirmació, apareix un text indicant que cal prémer la tecla Intro per realitzar l’operació. Quan finalitza correctament l’acció, es mostra un missatge a la mateixa pantalla, però amb tots els camps protegits. També existeix la possibilitat de que una vegada s’arriba a la pantalla de confirmació, no es vulgui realitzar l’acció. Per aquests casos sempre tenim la possibilitat de retrocedir per on em vingut i així no es realitza cap acció.

Per últim, tenim que l’acció es realitza correctament i es dona per acabada una unitat de diàleg. S’ha d’indicar que l’acció s’ha realitzat correctament i mostrar la següent pantalla. Es sol mostrar la pantalla que estadísticament es va a utilitzar després de realitzar l’acció, d’aquesta manera es facilita a l’usuari els accessos. Normalment la pantalla mostrada sol ser la mateixa, amb la possibilitat d’introduir dades noves, o el menú des d’on hem accedit.

Zona d’Accions Addicionals i/o Possibles

És la zona on es mostren aquelles accions addicionals i/o possibles respecte les accions estàndards que es realitzen des de la pantalla. Únicament es posen a les pantalles que ho necessiten.

S’entén per accions addicionals aquelles opcions complementaries a la pròpia funció de la pantalla. Sempre s’implementen amb camps de selecció d’accions.



Les accions possibles són aquelles que pot realitzar el terminalista sobre les dades mostrades a la pantalla, seleccionant solament una. Es representa de la següent manera:

• Per Tecles de Funció: Podem introduir fins tres noves accions.

• Per Camps de Selecció d’Accions: S’utilitza per realitzar més de tres accions o

més d’una acció simultàniament. S’introdueixen les possibles accions junt amb un camp de selecció.

• Per Secció d’un Valor Dintre d’un Menú: Podem tenir més de tres accions

però només es pot seleccionar una. Es crea un menú a la part inferior de la pantalla amb les accions possibles.

Zona de Missatges de Sistema

S’ha de incloure en totes les pantalles i és la zona on es mostren els missatges que envia el terminal

Zona de Tecles de Funció

Conté informació sobre les accions estàndards disponibles a la pantalla. S’ha de incloure en tots els tipus de pantalla.



2.3.7. Disseny de Transaccions STO

En aquest apartat es pretén introduir els conceptes bàsics del sistema On-Line del client, conegut amb el nom de STO (State Technology Office). És necessari tenir clars aquests conceptes per entendre posteriorment el projecte realitzat.

Una transacció On-Line és aquella que parteix d’una pantalla, analitza les dades d’entrada, fa els accessos a les BDs (Data Base) i posteriorment mostra els resultats a traves d’una o més pantalles. Per tant una transacció engloba formats de pantalla, un programa i bases de dades. Les transaccions funcionen sobre l’entorn IMS del sistema operatiu. Tot això es realitza com una operació automàtica, assegurant que no es modifiquen les dades fins que la transacció no ha finalitzat correctament.

Figura 3. Esquema Transacció STO

Els formats de les pantalles d’interfície amb l’usuari (també conegut com terminalista per està utilitzant el terminal que esta connectat al Host) per l’entrada i sortida de dades, es creen a partir de la definició de la pantalla amb la eina CASE. Es compon d’una capçalera estàndard i d’una sèrie de camps de dades, d’entrada o de sortida. La part del sistema operatiu encarregada de gestionar aquesta entrada i sortida de dades es diu FRONTEND.

Existeix una estructura de dades on es guarda tota l’informació que s’introdueix per la pantalla. Aquesta estructura rep el nom de “MID” (Module Input Date). Quan el programa vol saber quines dades s’han introduït per la pantalla no consulta la pantalla directament, sinó el MID.



A l’hora d’informar la pantalla amb les dades que es volem mostrar, no es realitza directament, s’utilitza una estructura de dades anomenada “MOD” (Module Output Data). En aquesta estructura es guarden totes les dades de la pantalla més els atributs d’aquestes. Les dades s’informen des del programa amb l’informació que ha d’aparèixer a la pantalla.

La PSB (Program Specification Block) defineix les bases de dades a les que accedirà la transacció.

El programa, també anomenat programa director és el que s’encarrega de executar els càlculs o les gestions de dades i està composat per mòduls, cada un amb una funció ven diferenciada. Resumint:

• Mòdul de Tractament d’Entrada, “post-frontend” o “post”: Gestiona i valida les dades que van des de la pantalla de l’usuari al programa i prepara l’execució dels mòduls d’aplicació.

• Mòdul d’Aplicació: Són els mòduls encarregats de realitzar l’acció. Venen a

ser el cor del programa i en poden haver-hi un o més.

• Mòdul d’Anàlisi de Resposta: És opcional i s’executa associat a un mòdul de aplicació. Analitza i gestiona les dades de sortida del mòdul d’aplicació. D’aquesta manera ens permet reutilitzar els mòduls. Aquest sistema es útil quan el mòdul d’aplicació no retorna les dades de la manera desitjada, sobretot si el mòdul no pertany a la mateixa aplicació que la transacció. També es pot utilitzar per inicialitzar les dades d’entrada del següent mòdul, si no es coneixen a priori i s’obtenen a partir de l’execució d’un mòdul d’aplicació anterior.

• Mòdul de Tractament de Sortida, “pre-frontend” o “pre”: A partir dels

resultats dels mòduls d’aplicació munta i presenta la pantalla de resposta a l’usuari.

La “conversa” és una estructura de dades que s’utilitza per anar guardant les dades de les pantalles a mesura que es va “navegant” per elles. En condicions normals, el fet de retrocedir per la navegació significa haver de tornar a generar la sortida de les pantalles anteriors, amb la pèrdua de temps que comporta. En canvi, amb la “conversa”, que té una estructura de pila, cada vegada que es passa a una altra pantalla s’apilen les dades de la pantalla anterior de manera que al retrocedir en la navegació solament s’ha d’anar desapilant de la “conversa” les dades de la pantalla anteriors (el que es denomina “conversa” de les pantalles anteriors). A més a més dels camps de la pantalla (“MOD”), es guarden altres dades que no són visibles i que serveixen per traspassar informació de una pantalla a una altra.



Així, quan el mòdul de sortida omple els camps d’una pantalla (“MOD”) també omplirà la “conversa” d’aquesta pantalla, el que rep el nom de gravar conversa. I el mòdul d’entrada, quan rep les dades de la pantalla (“MID”) també llegeix les dades de la seva “conversa”, o sigui, recupera la conversa. L’On-Line que utilitza la “conversa” es denomina On-Line conversacional.

En cada transacció es pot definir diferents fluxos de programa. Normalment es declaren les transaccions amb un mòdul d’entrada i un mòdul de sortida, però podem tenir més d’un mòdul d’aplicació depenent del treball a realitzar. En cada flux de programa es defineixen els mòduls que s’han d’executar seqüencialment, però no sempre es realitza la mateixa operació. Es defineix un flux diferent depenent de les operacions a realitzar. El flux a seguir durant l’execució d’una transacció es decideix en el mòdul d’entrada i normalment depèn de les dades d’entrada o de les dades de conversa (altres pantalles).

2.3.8. Les Bases de Dades

El client proporciona dos tipus diferents de bases de dades, que coexisteixen en el sistema.

Originalment, les bases de dades es definien en un entorn DL/I. Es tracta d’un sistema antic i en desús. No és un sistema relacional, tal y com es sol donar en l’actualitat, sinó que es jeràrquic, on s’agrupen les dades en forma de arbre. Cada node d’aquest arbre té una estructura de dades concreta i se li diu segment. L’avantatge que té el DL/I és la seva fiabilitat, robustesa i eficàcia, encara que hagi de tractar milions de dades.

L’altre tipus de base de dades que s’utilitza és el sistema relacional DB2 d’IBM, que permet SQL i que té una utilització més senzilla. Actualment les taules noves ja s’estan creant sota un sistema relacional. Però per qüestions de rendiment no s’han migrat totes les dades. L’eficàcia del DB2 amb una elevada quantitat de dades no compleix amb els requeriments mínims. De manera que el DB2 solament es pot utilitzar en casuístiques en que es tracten relativament poques dades, encara que es va ampliant la seva utilització a mesura que IBM optimitza el motor d’aquesta base de dades i actualitza les versions.

En resum, podem dir que s’estan migrant les de bases de dades del sistema DL/I a DB2, ja que aquestes són més senzilles de gestionar, però actualment no poden gestionar totes les dades amb DB2. Les bases de dades relacionals no ens proporcionen respostes acceptables amb grans quantitats de dades, per lo que ens ofereix més garanties una base de dades jeràrquica.



2.4. Bases de Dades Utilitzades

A continuació s’exposarà breument el disseny de les bases de dades de targetes, d’aquesta manera podrem veure com es guarda l’informació. Cal tenir en compte que el sistema que s’utilitza a les bases de dades de l’aplicació es coneix amb el nom de DL/I i es tracta d’un sistema jeràrquic. És a dir, tenim una base de dades “Pare” d’on pengen els seus “fills”.

Les bases de dades de l’aplicació segueixen la següent estructura:

• APLB01Z: Base de dades amb incidències d’una targeta.

Dins d’aquesta base de dades podem tenir diferents visions (Fills) dividides

amb els següents segments (Estructures de dades):

APLS010: Expedients d’incidències. APLS011: Successos d’un expedient. APLS012: Dades captura de l’operació. APLS013: Comentaris.

• APLB02Z: Base de dades de targetes amb incidències.

Dins d’aquesta base de dades podem tenir diferents visions (Fills) dividides amb els següents segments (Estructures de dades):

APLS020: Targetes. APLS021: Expedients d’una targeta.

• APLB03Z: Base de dades amb les dades mestres de les targetes.



2.4.1. APLB01Z. Incidències de Targetes:

En aquesta base de dades disposem de tot l’històric sobre accions que s’han realitzat per resoldre una reclamació.

A continuació veurem la utilitat de cada segment que forma part de la base de dades:

2.4.1.1. APLS010. Expedients d’Incidències

En el moment que es detecta una incidència en una operació amb targeta, ja sigui de crèdit o de dèbit, s’obre un expedient on quedaran reflexades totes les accions portades a terme per resoldre l’incidència.

En un expedient es guardarà tota l’informació necessària, com el PAN (Personal Account Number)1 de la targeta, la referència d’intercanvi, el número de successos de l’expedient i moltes més dades.

Un expedient s’identifica amb una única operació, això significa que si un client té cinc reclamacions tindrà cinc incidències obertes amb els seus corresponents expedients. Per associar un expedient amb una operació s’utilitza la referència d’intercanvi. Així el conjunt que forma el PAN més la referència d’intercanvi ens identificaran un únic expedient.

Existeixen, bàsicament, tres maneres per iniciar un procés de reclamació d’una operació:

Reclamació del client. Recepció d’una reclamació. Alta d’un rebuig.

1 Numeració amb la que s’identifiquen les targetes bancàries. La longitud d’aquest número sol estar entre 16 i 22 caràcters, depenent del tipus de tarjeta.



Reclamació del Client:

Un client de la nostre entitat detecta que se li ha carregat una operació amb la que no està d’acord i inicia un procés de reclamació.

Figura 4. Alta per reclamació de client

En aquest cas el moviment que es vol reclamar es va realitzar amb una targeta de la nostra entitat però en un TPV d’una altra entitat. Per tant, una vegada s’introdueixen les dades de la reclamació es genera un expedient d’incidència donant-se d’alta a la bases de dades de l’entitat. Posteriorment s’envia a SERMEPA (Servei per a Mitjans de Pagament) on es valida tota la informació de l’expedient i si esta correcte el fa arribar a l’entitat adquirent.

Base de dades de la nostra Entitat

Reclamació del Client

Enviament a Intercanvi

Entitat SERMEPA Adquirent

Externa



Recepció d’una Reclamació.

Quan el client d’una altra entitat financera detecta una incidència s’inicia el procés de reclamació. En aquest cas la nostra entitat actuaria com a entitat adquirent.

Reclamació d’un Client

Extern

Figura 5. Alta per recepció de reclamació

Es tracta del cas invers al punt anterior. Una altra entitat financera inicia una reclamació d’un client seu que ha realitzat una operació a traves d’un TPV de la nostra entitat. Una vegada SERMEPA a validat les dades, ens fa arribar la reclamació, la qual s’introdueix a la base de dades de reclamacions com a un nou expedient.


Enviament a Intercanvi

Entitat SERMEPAEmisora

Externa



Alta d’un Rebuig.

Quan es realitza una operació amb una targeta d’una altra entitat a un TPV de la nostra entitat, aquesta sol·licita a l’entitat emissora de la targeta l’import de l’operació. Això es realitza enviant l’operació a SERMEPA i una vegada es valida l’informació, es fa arribar a l’entitat emissora perquè aboni l’import. Quan l’informació que s’envia no és correcte, l’entitat emissora rebutja l’operació. Quan passa això, es genera un expedient d’incidència per rebuig a la base de dades de la nostra entitat.

Presentació a

Figura 6. Alta per rebuig


Intercanvi Entitat

Adquirent

SERMEPAEntitat

Emissora Externa

Recepció de l’Intercanvi



2.4.1.2. APLS011. Succés d’un Expedient.

Com ja hem comentat anteriorment, en un expedient es registraran totes les accions que es realitzen sobre ell per tal de realitzar la reclamació. Aquestes accions es veuen a l’expedient en forma de successos. Per tant, podem considerar que un succés és una acció que es realitza. En aquests successos guardarem totes les dades necessàries perquè junt amb les dades conservades a l’expedient es pugui reconstruir l’operació que va originar la reclamació.

Per exemple, quan un client detecta algun càrrec que ell considera incorrecte, es dirigeix personalment a l’oficina i sol·licita que li retornin l’import de l’operació.

Tipus de Successos:

En un expedient podem trobar els següents tipus de successos:

• Petició de Fotocopia: En aquest succés sol·licitem la fotocòpia del rebut de compra. També podem sol·licitar l’original, és a dir, en lloc de sol·licitar una copia es sol·licita l’original firmat pel client.

• Petició de Retrocessió: Ja sigui de factura, devolució o bestreta.

• Enviaments: Quan es detecta que un moviment ha d’anar a intercanvi per

continuar amb el procés de reclamació, ens apareix aquest tipus de succés amb el literal de “enviament a compensar”

• Rebuig: Quan enviem qualsevol moviment a intercanvi, aquest ens pot ser

retornat en forma de rebuig, quan això passa s’introdueix a la base de dades un succés de rebuig. Aquest succés contindrà tota l’informació del succés enviat. (Podrem observar com un rebuig apareix lligat a un altra tipus de succés)

• Reenviament: Quan es produeix un rebuig, després de detectar la causa del

rebuig i corregir-la (si és necessari), es procedeix al reenviament del moviment rebutjat. (Només es podran reenviar els successos que hagin sigut rebutjats).

• Traspàs: Existeix una opció a l’operativa per traspassar la gestió de la

reclamació d’una oficina a una altra. D’aquesta manera, l’oficina que s’encarregarà de gestionar la reclamació serà la destinatària del traspàs. El succés de traspàs serà idèntic al succés contra el que s’ha actuat. És a dir, si es traspassa una retrocessió, el succés de traspàs es considerarà com una retrocessió.



• Resolució: Existeixen una sèrie d’opcions dins de l’operativa per tal de resoldre reclamacions. Aquestes resolucions, actuen contra successos ja existents, generant nous successos on queda registrada la resolució de la reclamació. Ens podem trobar amb els següents tipus de resolució:

Apunt Estalvi/Estalvi Automàtic: Aquests dos literals es poden observar

quan la resolució efectuada ha sigut en contra o a favor del client (depenent del tipus de succés serà un carrega o un abonament) i se li realitza la carrega/abonament al seu compte.

Apunt Extracte: Aquest literal també es presenta en resolucions en contra

o a favor del client, però carregant l’import a l’extracte de la targeta de crèdit.

Pas a Caixa: Aquest literal es presenta quan es resol contra el compte de

l’oficina. Aquest succés no tindrà més efecte sobre el procés de reclamació.

Pas a Pèrdues i Guanys: Com en el cas anterior, aquest tipus de resolució afecta a un compte de resultats (Compte de pèrdues i guanys).

• Anul·lacions: Quan s’anul·la un succés, aquest no es borra de la base de dades,

quedant en un estat en que no hi haurà cap efecte ni contra el procés de reclamació ni comptablement. Val la pena comentar que un succés pot ser anul·lat sempre que estigui no consolidat, es a dir que el succés sigui del dia en curs.

• Cobrament/Pagament entre Entitats: Aquest tipus de succés són bàsicament

intercanvis de diners entre entitats. Pot ser el resultat d’un arbitratge (Quan en un procés de reclamació les dos entitats no es posen d’acord, es realitza un arbitratge), o recompensa.



Seqüència de Successos

Dintre del mateix expedient, els successos estan numerats per ordre d’inserció, però això no vol dir que sigui l’ordre del procés de reclamació. Cada succés ens indica quin número de succés és la seva acció posterior i la seva acció anterior.

Per exemple, a un client se li carrega dos vegades la mateixa factura i cap de les dos és seva. Suposant que els dos moviments són idèntics, l’expedient generat tindrà dos successos de petició de fotocòpia. Els dos s’envien a intercanvi i al cap d’uns dies ens rebutgen la primera petició i posteriorment es reenvia sense cap altre rebuig. Al cap d’un temps, l’entitat adquirent ens representa una factura. Aquesta es traspassa a l’oficina gestora de la targeta i se li acaba carregant al client.

No. Succés Tipus Anterior Posterior 1 Apunt Estalvi Retrocessió Factura 3 2 Apunt Estalvi Retrocessió Factura 4 3 Enviament Compensar Ret. Factura 1 7 4 Enviament Compensar Ret. Factura 2 5 5 Rebuig Tècnic Ret. Factura 4 6 6 Reenviament Ret. Factura 5 8 7 Pas a Caixa Retrocessió Factura 3 8 Recepció Factura Venta 6 9 9 Traspàs a XXXX Factura de Venta 8 10 10 Apunt Estalvi Factura de Venta 9

Figura 7. Quadre Exemple Expedient



En la taula anterior podem observar com les dos retrocessions segueixen dos camins diferents, un acaba compensada passant a resultats i l’altra s’acaba tornant i es carrega al client la factura reclamada.

Expedient

Apunt Estalvi Ret. Factura 2

Enviament Comp. Ret. Factura 4

Figura 8. Dos Camins en un Mateix Expedient

Amb aquest esquema podem veure que la seqüència lògica del succés la determina la relació entre un succés i el seu anterior i posterior.

Apunt Estalvi Ret. Factura

Rebuig Ret. Factura

Enviament Comp. Ret. Factura

Pas a Caixa Ret. Factura

Reenviament Retroc. Factura.

Recepció Factura Venta

Traspàs a oficina Factura

Apunt Estalvi Factura

1

5

3

6

7

8

9

10



2.4.1.3. APLS012: Dades Captura de l’Operació

Quan s’actua com a entitat adquirent de la reclamació s’inicia una cerca del moviment en qüestió. Aquests procediments de cerca acaben donant com a resultat la generació d’un segment APLS012 el qual es pot consultar a traves de l’operativa On-Line. D’aquesta manera, la persona que té de resoldre una reclamació tindrà a la seva disposició totes les dades possibles referents a l’operació.

2.4.1.4. APLS013: Comentaris

Existeix la possibilitat que un expedient o succés estigui acompanyat de unes línies de comentari. Aquests comentaris es poden donar d’alta les diferents persones que intervenen en la resolució de la reclamació i d’aquesta manera detallar la situació de la mateixa.

2.4.2. APLB02Z: Base de Dades de Targetes amb Incidències

En aquesta base de dades s’emmagatzemen les targetes que tenen reclamacions pendents i les referències d’intercanvi de les operacions reclamades.

2.4.2.1. APLS020: Targetes

En aquest segment s’emmagatzema el PAN de la targeta.

Quan es dona d’alta un expedient, si la targeta no existeix a la base de dades, també es dona d’alta. A les hores, per saber si una targeta té reclamacions en curs, només s’haurà de realitzar una consulta dels expedients de la targeta.



2.4.2.2. APLS021: Expedients d’una Targeta

En aquest segment s’emmagatzemen les referències d’intercanvi de les operacions reclamades.

Existeix una relació entre les dos bases de dades que em vist fins al moment:

APLS020 Targetes

APLS010 Expedient X

APLS021 APLS021 Referència X Referència Y

APLS010 Expedient Y

Figura 9. Relació entre APLB02Z i APLB01Z

2.4.3. APLB03Z: Base de Dades amb les Dades Mestres de les Targetes

En aquesta base de dades s’emmagatzema la informació necessària per l’aplicació, tant pel seu funcionament intern com a nivell d’intercanvi amb altres entitats.

Fins aquí s’ha explicat d’una manera compacta i resumida com estan organitzades les bases de dades de la nostra aplicació, a més a més, em pogut observar mitjançant exemples com funciona l’operativa. La resta de bases de dades que utilitza la nostra aplicació no les explicarem ja que les bases de dades que hem utilitzat al projecte en un 90% són les nostres que han estat anteriorment explicades.



2.5. Projecte Realitzat a l’Empresa

2.5.1. Introducció

En aquesta apartat explicarem breument en que consisteix el projecte realitzat dins l’empresa. El projecte tenia com objectiu, la renovació d’una part de l’aplicació de targetes i la creació de noves funcions necessàries actualment.

L’adaptació al nou projecte comportava l’elaboració de nous programes i la modificació d’altres existents així com el reformateig de diferents bases de dades per adaptar-les a les noves especificacions.

Per realitzar tot això s’ha tingut de realitzar les següents feines:

• Definició i creació d’objectes a partir de l’eina CASE

⇒ Definició de mòduls de codi font a utilitzar. ⇒ Creació de la interfície d’usuari a utilitzar per l’oficinista.

• Programació de les aplicacions en llenguatge PL/I (Programming Language)2

⇒ Transaccions que controlen l’aplicació On-Line. ⇒ Processos Batch.

• Programació de processos Batch en llenguatge JCL (Job Control Language)

En aquesta aplicació s’utilitzen fitxers d’entrada/sortida i bases de dades DL/I (Bases de dades jeràrquiques) i DB2 (Utilitzant SQL, Cursos, etc.).

2 El PL/I va ser desenvolupat per IBM l’any 1960, i el seu nom original era NPL (New Programming Language). Aquest nom es va canviar ja que originava confusions amb NPL (National Physical Laboratory)



2.5.2. Generació de Pantalles

CONFIDENCIAL

Aquesta part del projecte conté informació confidencial i no ha estat

publicada, per obtenir informació adreçar-se a:

Enric Vidal Idiarte Telèfon : 977 559 622 Fax : 977 559 605 E-mail : [email protected]



2.5.3. Disseny

Per poder iniciar l’elaboració del programa que gestiona aquestes pantalles s’han de generar uns patrons de totes les parts que utilitzarem. Entre aquestes parts està el POST (mòdul d’entrada), el PRE (mòdul de sortida) i els mòduls d’aplicació. El POST s’encarrega de validar les dades que s’han introduït per pantalla. Aquesta validació sol ser sintàctica, ja que en aquesta part del programa no s’accedeix a cap base de dades. També s’encarrega de gravar el missatge circulant. D’aquesta manera passem les dades introduïdes per pantalla als mòduls d’aplicació els quals si accedeixen a les bases de dades.

El mòdul d’aplicació s’encarrega bàsicament d’accedir a les diferents bases de dades que necessitem, i segons el tipus d’operació que estiguem realitzant, les consultarà, eliminarà o modificarà.

El PRE s’encarregarà de gravar la conversa i mostrar la pantalla que estem tractant.

2.5.4. Implementació

2.5.4.1. Entorn de Treball

Tot el treball s’ha realitzat a l’entorn Host del client, amb màquines IBM que incorporen el sistema operatiu MVS (Multiple Virtual Storage). Aquest sistema operatiu disposa d’eines de treball com l’IMS (Information Management System) , el TSO (State Technology Office), etc. Aquestes eines faciliten els treballs d’edició, compilació, proves, control de qualitat, etc.



2.5.4.2. Codi del Programa

L’editor que s’utilitza per codificar els programes ve facilitat pel sistema operatiu i té el següent aspecte:

Figura 13. Editor Codi HOST

Tot el codi que s’ha generat està destinat a l’operativa On-Line, es a dir, per la correcta interacció de les diferents pantalles que s’han generat per l’operativa.

Per cada nova pantalla que s’ha generat se li ha assignat un nom de transacció, un POST, un PRE i un mòdul de aplicació. Per tal d’aprofundir amb el codi que s’ha realitzat, explicarem la transacció que controla la pantalla de resolucions contra pèrdues i guanys que és la APLT827. A continuació detallarem quina és la funció dels diferents components que l’integren:



Mòdul d’Entrada o POST:

La principal funció d’aquest mòdul és recuperar les dades que li arriben per la conversa. Això ens servirà per tenir totes les dades de la pantalla per si es vol retrocedir a la pantalla anterior. Aquest mòdul també s’encarrega de validar les dades que l’usuari ens pot introduir per pantalla. A la pantalla de resolució contra pèrdues i guanys existeixen tres camps d’entrada:

• Codi de motiu: S’ha de validar que aquest s’hagi informat i sigui numèric.

• Numero Empleat: S’ha de validar que aquest camp s’hagi informat juntament

amb el camp del password.

Aquests camps són obligatoris i per realitzar correctament la resolució contra pèrdues i guanys han d’estar els tres correctament informats. En cas contrari s’aniran mostrant missatges d’error per pantalla fins aconseguir que l’usuari els informi correctament.

• Centre Destí: Es tracta d’un camp no obligatori i s’ha d’informar amb un

número d’oficina. En el cas que no s’informi aquest camp, el programa l’informarà internament amb el número de l’oficina gestora.

Una vegada s’ha validat la correcta informació dels camps i la seva validesa sintàctica, muntarem el missatge circulant amb les dades necessàries i el flux de la transacció.

El flux és una sèrie de paràmetres que indiquen quin o quins mòduls d’aplicació s’han d’executar per aquesta transacció i en quin ordre ho faran.

Si l’execució del mòdul d’entrada no dona cap error i arriba fins al final, es passa a executar el mòdul d’aplicació que serà l’encarregat d’accedir a les bases de dades.



Mòduls d’Aplicació

El nostre mòdul d’aplicació s’encarregarà d’accedir a les bases de dades que siguin necessàries per tal de:

• Validar que el codi de motiu que s’ha introduït existeixi i sigui vàlid.

• Comprovar que el succés compleix les condicions exigides per poder-se

resoldre a pèrdues i guanys.

• Si totes les validacions han sigut correctes, generar un nou succés de resolució contra pèrdues i guany informant les bases de dades corresponents.

Per tal de realitzar totes les accions anteriors, els passos que es segueixen dins del mòdul són els següents:

• Validar que tots els camps d’entrada al mòdul d’aplicació (que els camps

vinguin informats, que el codi de motiu que ens arriba existeixi, etc.) siguin correctes i en el cas que no ho siguin, donar un error de mòdul i gravar una incidència amb informació sobre l’error.

• Realitzem una lectura de l’expedient que estem tractant per tal d’obtenir les

seves dades i validar que existeixi.

• Realitzarem una lectura del succés que s’està tractant per tal d’obtenir les seves dades i validar que existeixi.

• A partir de les dades obtingudes de lectura del codi de motiu, expedient i

succés, validarem que es pugui realitzar l’acció.

• Modifiquem el succés que estem tractant i el deixem com a resolt.

• Inserim un nou succés a l’expedient com a resolució contra pèrdues i guanys.

• Modifiquem les dades de l’expedient per indicar que ara té un succés més.

• Informem les àrees de sortida del mòdul d’aplicació.



L’execució d’un mòdul d’aplicació no sempre ha d’anar bé, ja que es poden produir errors inesperats. Per informar a la transacció com ha anat l’execució del mòdul, aquest retorna un camp amb el seu estat. Els retorns possibles que pot tenir un mòdul d’aplicació són:

• OK El mòdul ha acabat correctament. • NOK S’ha produït un error al mòdul i no s’ha realitzat cap operació.

• NP S’ha produït un error al mòdul al accedir a les BD’s i no s’ha realitzat cap operació.

Una vegada sortim del mòdul d’aplicació, només ens queda tracta el mòdul de sortida.

Mòdul de Sortida o PRE:

Aquest mòdul s’encarrega bàsicament de tractar les dades que ens arriben del mòdul d’aplicació i muntar la pantalla amb l’informació que correspongui.

Quan es munta la pantalla amb l’informació, si tot ha anat bé, es mostra un missatge informatiu indicant que l’operació s’ha realitzat correctament. D’igual manera, si s’ha produït un error en el mòdul d’aplicació, es mostrarà un missatge on s’indica el motiu de l’error.

2.5.5. Problemes Durant el Projecte

En aquest apartat es pretén explicar les dificultats que es troben al iniciar un projecte d’aquest tipus en un entorn desconegut.

El primer pas va consistir en saber el que s’estava fent i perquè s’estava fent. Va ser necessari informar-se sobre el sistema financer Espanyol i d’aquesta manera arribar a entendre els motius pels quals es realitzava aquest projecte.



El problema més gran que ens vam trobar durant la realització del projecte, va ser el gran nombre de canvis que es van haver d’implementar durant i després de finalitzar el projecte. Aquests canvis solien venir motivats per modificacions en els camps de les pantalles i nous requeriments per l’operativa. De tota manera, aquests canvis estaven subjectes a la modificació de codi dels mòduls ja implementats. Per aquest motiu calia tenir ven estructurat el codi per tal que aquests canvis i els futurs es pugessin implementar amb facilitat i que la resta seguis funcionant correctament.

Signat:



Plànols

3. Plànols.

Índex Índex.................................................................................................................. 1 5. Plànols....................................................................................................... 2

5.1. Diagrama de Flux de l’Operativa .......................................................................... 2 5.2. Esquema Centres Autoritzadors ............................................................................ 3

Plànols 1

3. Plànols.

5. Plànols

5.1. Diagrama de Flux de l’Operativa

APLX00 APLX10 APLX20

APLX30

APLX40

APLX50

APLX60

APLXA0

APLX70

Detall SuccésMenú Operativa Detall Incidencia

Env. 1era Retrocessió

Enviament Rebuig

Traspàs Incidència

Resolució I&G

Resolució P&G

Anul·lacions

Plànols 2

3. Plànols.

5.2. Esquema Centres Autoritzadors

Plànols 3

3. Plànols.

Signat:


Plànols 4

Pressupost

4. Pressupost.

Índex Índex.................................................................................................................. 1 4. Pressupost ................................................................................................. 2

4.1. Consideracions Inicials.......................................................................................... 2 4.2. Preus Unitaris ........................................................................................................ 3

4.2.1. Material ............................................................................................................. 3 4.2.2. Mà d’Obra ......................................................................................................... 3

4.3. Descomposició Tasques ........................................................................................ 3 4.3.1. Estudi Projecte .................................................................................................. 3 4.3.2. Creació Pantalles (Eina CASE) ........................................................................ 4 4.3.3. Codificació Mòdul d’Entrada (POST) .............................................................. 4 4.3.4. Codificació Mòdul de Sortida (PRE) ................................................................ 5 4.3.5. Codificació Mòdul d’Aplicació ......................................................................... 5 4.3.6. Proves i Validacions.......................................................................................... 6 4.3.7. Documentació.................................................................................................... 6

4.4. Descomposició Projecte ........................................................................................ 7 4.4.1. Transacció Menú Operativa.............................................................................. 7 4.4.2. Transacció Detall Incidència ............................................................................ 7 4.4.3. Transacció Detall Succés .................................................................................. 8 4.4.4. Transacció Enviament Primera Retrocessió ..................................................... 8 4.4.5. Transacció Enviament Rebuig........................................................................... 9 4.4.6. Transacció Traspàs Incidència ......................................................................... 9 4.4.7. Transacció Resolució Contra Ingressos i Despeses........................................ 10 4.4.8. Transacció Resolució Contra Pèrdues i Guanys............................................. 10 4.4.9. Transacció Anul·lacions .................................................................................. 11

4.5. Resum del Pressupost .......................................................................................... 12

Pressupost 1

4. Pressupost.

4. Pressupost

4.1. Consideracions Inicials

Cal tenir en compte que els preus que hi figuren en aquest pressupost són orientatius i que el número d’hores i els materials necessaris poden anar variant durant l’elaboració del projecte, provocant variacions en el pressupost.

Normalment l’elaboració d’un pressupost es veu afectat per la situació del mercat. La forta competència i la caiguda de la demanda en el sector informàtic ha provocat que els pressupostos siguin molt ajustats.

En els cas que estem tractant, l’empresa ja disposa de tot el material i infrastructures necessàries per realitzar aquests tipus de projectes. Per tant, en el pressupost no s’incorporarà l’adquisició del material, sinó l’amortització del mateix.

També cal destacar que l’empresa ja disposa del software necessari per desenvolupar aquest tipus de projectes i que per tant, les llicencies de software i tots els programes que s’utilitzaran només s’inclourà al pressupost la seva amortització.

Pressupost 2

4. Pressupost.

4.2. Preus Unitaris

4.2.1. Material Codi Unitat Designació Preu (Eur)101 h Amortització Equipament Hardware 1,00102 h Amortització Equipament Software 1,00

4.2.2. Mà d’Obra Codi Unitat Designació Preu (Eur)201 h Programador Sènior 15,00202 h Analista Programador 20,00203 h Analista Orgànic 30,00

4.3. Descomposició Tasques

En aquest apartat es detallen les diferents tasques que s’han de realitzar per arribar a obtenir els diferents components que integren el projecte.

4.3.1. Estudi Projecte Codi Partida Designació Unitat

T-001 Estudi i anàlisis del projecte i desenvolupament de la proposta de solució. un.

Unitat Quantitat Preu unitari Total (Eur)Material: 101- Amortització Equipament Hardware h 2,00 1,00 2,00102- Amortització Equipament Software h 2,00 1,00 2,00

Subtotal Material: 4,00 Mà d’obra:: 202- Analista Programador h 1,00 20,00 20,00203- Analista Orgànic h 1,00 30,00 30,00

Subtotal Material: 50,00 Cost Execució: 54,00

Pressupost 3

4. Pressupost.

4.3.2. Creació Pantalles (Eina CASE) Codi Partida Designació Unitat

T-002 Realització i generació d’una pantalla On-Line un. Unitat Quantitat Preu unitari Total (Eur)

Material: 101- Amortització Equipament Hardware h 1,00 1,00 1,00102- Amortització Equipament Software h 1,00 1,00 1,00

Subtotal Material: 2,00 Mà d’obra:: 201- Programador Sènior h 1,00 15,00 15,00


4.3.3. Codificació Mòdul d’Entrada (POST) Codi Partida Designació Unitat

T-003 Codificar i compilar correctament un mòdul d’entrada. un. Unitat Quantitat Preu unitari Total (Eur)




Pressupost 4

4. Pressupost.

4.3.4. Codificació Mòdul de Sortida (PRE) Codi Partida Designació Unitat

T-004 Codificar i compilar correctament un mòdul de sortida un. Unitat Quantitat Preu unitari Total (Eur)




4.3.5. Codificació Mòdul d’Aplicació Codi Partida Designació Unitat

T-005 Codificar i compilar correctament un mòdul de aplicació un. Unitat Quantitat Preu unitari Total (Eur)




Pressupost 5

4. Pressupost.

4.3.6. Proves i Validacions Codi Partida Designació Unitat

T-006 Realitzar proves i validacions de totes les operatives. un. Unitat Quantitat Preu unitari Total (Eur)


Subtotal Material: 4,00 Mà d’obra:: 201- Programador Sènior h 1,00 15,00 15,00202- Analista Programador h 1,00 20,00 15,00


4.3.7. Documentació Codi Partida Designació Unitat

T-007 Realitzar tota la documentació de les proves de l’operativa. un. Unitat Quantitat Preu unitari Total (Eur)




Pressupost 6

4. Pressupost.

4.4. Descomposició Projecte

Detallem les pautes que s’han de seguir per obtenir els diferents apartats del projecte. Observarem que per algunes transacció no és necessària la codificació d’un mòdul d’aplicació nou, ja que es poden reutilitzar mòduls ja existents.

4.4.1. Transacció Menú Operativa Codi Projecte Designació Unitat

P-001 Feines a realitzar per crear el menú principal de l’operativa un. Unitat Quantitat Preu unitari Total (Eur)

Tasques: T001 – Estudi Projecte. h 5,00 54,00 270,00T002 – Creació Pantalla. h 4,00 17,00 68,00T003 – Codificació mòdul d’entrada. h 20,00 17,00 340,00T004 – Codificació mòdul de sortida. h 20,00 17,00 340,00T006 – Proves i validacions. h 20,00 39,00 780,00T007 – Documentació. h 20,00 17,00 340,00

Cost Execució: 2.138,00

4.4.2. Transacció Detall Incidència Codi Projecte Designació Unitat

P-002 Feines a realitzar per crear el detall de l’incidència. un. Unitat Quantitat Preu unitari Total (Eur)



Pressupost 7

4. Pressupost.

4.4.3. Transacció Detall Succés Codi Projecte Designació Unitat

P-003 Feines a realitzar per crear el detall del succés. un. Unitat Quantitat Preu unitari Total (Eur)



4.4.4. Transacció Enviament Primera Retrocessió Codi Projecte Designació Unitat

P-004 Feines a realitzar per crear l’enviament de una 1era retro. un. Unitat Quantitat Preu unitari Total (Eur)

Tasques: T001 – Estudi Projecte. h 5,00 54,00 270,00T002 – Creació Pantalla. h 4,00 17,00 68,00T003 – Codificació mòdul d’entrada. h 20,00 17,00 340,00T004 – Codificació mòdul de sortida. h 20,00 17,00 340,00T005 – Codificació mòdul d’aplicació. h 40,00 17,00 680,00T006 – Proves i validacions. h 20,00 39,00 780,00T007 – Documentació. h 20,00 17,00 340,00


Pressupost 8

4. Pressupost.

4.4.5. Transacció Enviament Rebuig Codi Projecte Designació Unitat

P-005 Feines a realitzar per crear l’enviament d’un rebuig un. Unitat Quantitat Preu unitari Total (Eur)



4.4.6. Transacció Traspàs Incidència Codi Projecte Designació Unitat

P-006 Feines a realitzar per crear el traspàs de l’incidència. un. Unitat Quantitat Preu unitari Total (Eur)



Pressupost 9

4. Pressupost.

4.4.7. Transacció Resolució Contra Ingressos i Despeses Codi Projecte Designació Unitat

P-007 Feines a realitzar per crear la resolució contra I&G. un. Unitat Quantitat Preu unitari Total (Eur)



4.4.8. Transacció Resolució Contra Pèrdues i Guanys Codi Projecte Designació Unitat

P-008 Feines a realitzar per crear la resolució contra P&G. un. Unitat Quantitat Preu unitari Total (Eur)



Pressupost 10

4. Pressupost.

4.4.9. Transacció Anul·lacions Codi Projecte Designació Unitat

P-009 Feines a realitzar per crear l’anul·lació. un. Unitat Quantitat Preu unitari Total (Eur)



Pressupost 11

4. Pressupost.

4.5. Resum del Pressupost

Capítols Import P001 – Transacció Menú Operativa. 2.138,00P002 – Transacció Detall Incidència 2.138,00P003 – Transacció Detall Succés 2.138,00P004 – Transacció Enviament Primera Retrocessió 2.818,00P005 – Transacció Enviament Rebuig 2.818,00P006 – Transacció Traspàs Incidència 2.818,00P007 – Transacció Resolució Contra Ingressos i Despeses 2.818,00P008 – Transacció Resolució Contra Pèrdues i Guanys 2.818,00P009 – Transacció Anul·lacions 2.818,00

Total Pressupost d’Execució Material : 23.322,00 Despeses Generals 13% 3.031,86Benefici 6% 1.399,32

Total Parcial : 27.753,18 I.V.A. 16% 4.440,51

Total Pressupost : 32.193,69 El pressupost ascendeix a la quantitat de trenta-dos mil cent noranta-tres amb seixanta-nou euros. Signat:


Pressupost 12

Plec de Condicions

5. Plec de Condicions.

Índex Índex.................................................................................................................. 1 5. Plec de Condicions ................................................................................... 2

5.1. Condicions Generals.............................................................................................. 2 5.1.1. Introducció ........................................................................................................ 2 5.1.2. Reglaments i Normes ......................................................................................... 2 5.1.3. Execució del Programa ..................................................................................... 2

5.1.3.1. Inici............................................................................................................ 2 5.1.3.2. Termini d’Execució ................................................................................... 3

5.1.4. Interpretació i Desenvolupament del Programa............................................... 3 5.1.5. Treballs Complementaris .................................................................................. 4 5.1.6. Modificacions .................................................................................................... 4 5.1.7. Programa Defectuós.......................................................................................... 4 5.1.8. Mitjans Auxiliars ............................................................................................... 5 5.1.9. Conservació del Programa................................................................................ 5 5.1.10. Recepció del Programa ................................................................................. 5

5.1.10.1. Recepció Provisional ............................................................................. 5 5.1.10.2. Llicencies i Drets ................................................................................... 5 5.1.10.3. Termini de la Garantia........................................................................... 6 5.1.10.4. Recepció Definitiva ............................................................................... 6

5.1.11. Contractació de la Empresa Programadora................................................. 6 5.1.11.1. Mode de Contractació............................................................................ 6 5.1.11.2. Presentació............................................................................................. 6 5.1.11.3. Selecció.................................................................................................. 6

5.1.12. Fiança............................................................................................................ 7 5.2. Condicions Econòmiques ...................................................................................... 7

5.2.1. Abonament del Programa.................................................................................. 7 5.2.2. Preus.................................................................................................................. 7 5.2.3. Revisió de Preus ................................................................................................ 8 5.2.4. Penalitzacions.................................................................................................... 8 5.2.5. Contracte ........................................................................................................... 8 5.2.6. Responsabilitats................................................................................................. 8 5.2.7. Rescissió del Contracte ..................................................................................... 9

5.2.7.1. Causes de Rescissió ................................................................................... 9 5.2.8. Liquidació en el Cas de Rescissió del Contracte ............................................ 10

5.3. Conclusions ......................................................................................................... 10

Plec de Condicions 1


5. Plec de Condicions

5.1. Condicions Generals

5.1.1. Introducció El present plec de condicions té com a objectiu definir a l’Empresa Programadora les característiques del seu treball i l’execució del mateix.

• El treball consisteix en la creació d’una aplicació informàtica i totes les

proves oportunes per assegurà la fiabilitat de la mateixa.

• L’Empresa Programadora s’encarregarà del disseny i implantació de l’aplicació informàtica.

5.1.2. Reglaments i Normes Totes les unitats que formen l’aplicació informàtica compliran tots els reglaments i normes tècniques d’obligat compliment per aquest tipus d’aplicacions, així com les descrites a la memòria descriptiva del projecte.

5.1.3. Execució del Programa

5.1.3.1. Inici

L’Empresa Programadora començarà la creació del programa en el termini que figura en el contracte, o en el seu defecte als quinze dies posteriors a l’adjudicació definitiva o signatura del projecte.

L’Empresa Programadora està obligada a notificar per escrit o personalment la data d’inici del projecte.



5.1.3.2. Termini d’Execució

El programa s’executarà en el termini que s’estipula al contracte subscrit amb l’Empresa Usuària.

L’Empresa Programadora, es compromet a facilitar inspeccions per part de l’Empresa Usuària de les parts finalitzades del projecte.

Quan el ritme de treball establert pel contractista no sigui el normal, o bé a petició d’una de les parts, es podrà convenir una programació d’inspecció obligatòries d’acord amb el pla d’obra.

5.1.4. Interpretació i Desenvolupament del Programa L’interpretació tècnica del programa, correspon al Tècnic Director. L’Empresa Programadora està obligada a atendre a aquest per qualsevol dubte, aclariment o contradicció que sorgeixi durant l’execució del programa per causes d’una incorrecte interpretació, o circumstancies alienes, sempre amb la suficient antelació en funció de l’importància del tema.

L’Empresa Programadora es fa responsable de qualsevol error en l’execució motivada per l’omissió d’aquestes obligacions i conseqüentment haurà de refer i assumir el seu cost les feines que corresponguin de la incorrecta interpretació del projecte.

L’Empresa Programadora està obligada a realitzar tot el que sigui necessari per la correcte execució del programa, encara que no s’hagi expressat en el plec de condicions o en els documents del projecte.

L’Empresa Programadora notificarà per escrit o personalment de manera directe al Tècnic Director i amb la suficient antelació les dates en que quedaran preparades per inspeccionar cada una de les parts del programa per les quals s’ha indicat la necessitat o conveniència de les mateixes.



5.1.5. Treballs Complementaris L’Empresa Programadora té l’obligació de realitzar tots els treballs complementaris que siguin indispensables per l’execució de qualsevol part del programa especificat en qualsevol dels documents del projecte, encara que en ell, no constin explícitament mencionades aquest feines complementaries. Tot això sense la variació de l’import contractat.

5.1.6. Modificacions L’Empresa Programadora està obligada a realitzar les feines que se li encarreguin resultants de modificacions del programa, tant en augment com en disminució o simplement variacions, sempre i quan l’import de les mateixes no alteri en més o menys d’un 25 % del valor contractat.

La valoració de les mateixes es farà d’acord, amb els valors establerts en el pressupost presentat a l’Empresa Programadors i que ha sigut pres com a base del contracte. El Tècnic Director del programa està facultat per introduir les modificacions d’acord amb els seus criteris, en qualsevol part del programa, durant la creació, sempre que compleixi les condicions tècniques referides en el projecte i de manera que això no varií l’import total del programa.

5.1.7. Programa Defectuós Quan l’Empresa Programadora localitzi qualsevol part del programa defectuosa, que no s’ajusti a lo especificat en el projecte o en el plec de condicions, el Tècnic Director podrà acceptar o rebutjar; en el primer cas, aquest fixarà el preu que cregui just per arreglar les diferències que existissin, estan obligada l’Empres Programadora a acceptar aquesta valoració, en l’altre cas, es reconstruirà a expenses de l’Empresa Programadora la part mal executada sense que això sigui motiu de reclamació econòmica o d’ampliació del termini d’execució.



5.1.8. Mitjans Auxiliars Seran de l’Empresa Programadora tots els mitjans i maquines auxiliars que siguin necessàries per l’execució del Programa.

5.1.9. Conservació del Programa És obligatori de l’Empresa Programadora la conservació en prefecte estat del programa fins la data de recepció definitiva per l’Empresa Usuària, i corren al seu càrrec les despeses derivades.

5.1.10. Recepció del Programa

5.1.10.1. Recepció Provisional

Una vegada finalitzat el Programa, tindrà lloc la recepció provisional on es practicarà un detingut reconeixement per part del Tècnic Director i l’Empresa Usuària en presencia de l’Empresa Programadora, aixecant una acta i començant a corre des d’aquest dia el termini de garantia si es troba en l’estat per ser admès.

De no ser admès es farà constar en l’acte i es donaran instruccions a l’Empresa Programadora per solventar els defectes observats, fixant-se un nou termini de presentació, que una vegada expiri es procedirà a un nou reconeixement a fi de procedir a la recepció provisional.

5.1.10.2. Llicencies i Drets

Una vegada efectuada la recepció provisional se li donarà a l’Empresa Usuària una llicencia de drets d’us del programa, una copia del programa i un manual d’instruccions i us. Aquesta llicencia dona dret a instal·lar el programa en un ordinador. Per cada llicencia de drets d’us que es disposa, només es pot haver una copia en us, es a dir instal·lada en un ordenador. No es podrà copiar, instal·lar en un altre ordenador, executant a públic o lloguer la copia del programa sense la prèvia autorització de l’Empresa Programadora. Si es vol instal·lar el programa en un altra ordenador es tindrà que desinstal·lar prèviament del primer.



5.1.10.3. Termini de la Garantia

El termini de la garantia serà com a mínim d’un any, contant des de la data de la recepció provisional, o bé el que s’estableix en el contracte també contant des de la mateixa data. Durant aquest període queda a càrrec de la Empresa Programadora la conservació del Programa i la correcció dels errors observats.

5.1.10.4. Recepció Definitiva

Es realitzarà després de passar el termini de garantia i d’igual manera que la provisional. A partir d’aquesta data cessarà l’obligació de l’Empresa Programadora de conservar i reparar al seu càrrec els defectes observats.

5.1.11. Contractació de la Empresa Programadora

5.1.11.1. Mode de Contractació

El conjunt del programa el realitzarà l’empresa escollida per concurs - subhasta.

5.1.11.2. Presentació

Les empreses seleccionades per dit concurs hauran presentar els seus projectes en un sobre tancat, abans de la data indicada, en el domicili de l’Empresa Usuària.

5.1.11.3. Selecció

L’empresa escollida serà anunciada la setmana següent a la conclusió del termini de presentació. Dita empresa serà escollida de mutu acord entre la Empresa Usuària i el Director Tècnic, sense possibilitat de reclamació per part de les altres Empreses Concursants.



5.1.12. Fiança En el contracte s’estableix una fiança que l’Empresa Programadora haurà de dipositar en garantia del compliment del mateix, o es convindrà una retenció sobre els pagaments realitzats a compte de programa realitzat.

De no estipular-se la fiança en el contracte s’entén que s’adopta com a garantia una retenció del 5% sobre els pagaments.

La fiança retinguda s’abonarà a l’Empresa Programadora en un termini no superior a trenta dies una vegada firmada l’acta de recepció definitiva del programa.

5.2. Condicions Econòmiques

5.2.1. Abonament del Programa En el contracte s’haurà de fixar detalladament la manera i els terminis que s’abonaran les parts realitzades del programa. Les liquidacions parcials que poden establir-se tindran caràcter de documents provisionals a bon compte, subjectes a les certificacions que resulten de la liquidació final. No suposant, dites liquidacions, aprovació ni recepció del treball que comprenen.

Acabat el programa es procedirà a la liquidació final que s’efectuarà d’acord amb els criteris establerts en el contracte.

5.2.2. Preus L’Empresa Programadora presentarà, al formalitzar-se el contracte, la relació dels preus de les unitats del programa que integren el projecte, les quals han de ser acceptades, i tindran valor conceptual que s’aplicarà a les possibles variacions que poden haver.

Aquests preus unitaris, s’entenen que comprenen l’execució total de l’unitat del programa, incloent tots els treballs, els complementaris i els materials així com la part proporcional d’imposició fiscal, les carregues laborals i altres despeses repercutibles.

En el cas de tenir que realitzar-se unitats de programa no previstes en el projecte, es fixarà el seu preu entre el Tècnic Director i la Empresa Programadora abans d’iniciar el programa i es presentarà a l’Empresa Usuària per la seva acceptació o no.



5.2.3. Revisió de Preus En el contracte s’estableix si l’Empresa Programadora té dret a revisió de preus i la formula a aplicar per calcular aquesta revisió. En defecte d’aquesta última, s’aplicarà a judici del Tècnic Director algun dels criteris oficials acceptats.

5.2.4. Penalitzacions Per retard en els terminis d’entrada del programa, es podrà establir taules de penalització que les seves quantitats i demores es fixaran en el contracte.

5.2.5. Contracte El contracte es formalitzarà mitjançant documents privats, que podran elevar-se a escriptura pública a petició de qualsevol de les parts. Comprendrà l’adquisició de tots el materials, transport, mà d’obra, mitjans auxiliars per l’execució del programa projectat en el termini estipulat, així com la reconstrucció de les unitats defectuoses, la realització de les parts complementaries i les derivades de les modificacions que s’introdueixen durant l’execució.

La totalitat dels documents que componen el Projecte Tècnic del programa seran incorporades al contracte i tant el contractista com l’Empresa Usuària hauran de firmar en testimoni que els coneixen i els accepten.

5.2.6. Responsabilitats L’Empresa Programadora és la responsable de l’execució del programa a les condicions establertes al projecte i al contracte. Com a conseqüència de això vindrà obligat a l’eliminació de la mala execució i a la seva reconstrucció correctament sense que serveixi d’excusa que el Tècnic Director hagi examinat i reconegut el programa.

L’Empresa Programadora és l’única responsable de totes les contravencions que ella o el seu personal realitzin durant l’execució del programa o operacions relacionades amb el mateix. També és responsable dels danys que per errors, inexperiència o utilització de mètodes inadequats es produeixen a l’Empresa Usuària.

L’Empresa Programadora es l’única responsable del incompliment de les disposicions vigents en matèria laboral respecte de seu personal.



5.2.7. Rescissió del Contracte

5.2.7.1. Causes de Rescissió

Es consideren causes suficients per la rescissió del contracte les següents:

1. Mort o incapacitat de l’Empresa Programadora. 2. Fallida de l’Empresa Programadora. 3. Modificació del projecte quan es produeixen alteracions a més o menys

25% del valor contractat. 4. Modificació de les unitats de programa a números superiors al 40% de

l’original. 5. La no iniciació de la programació en el termini estipulat quan sigui per

causes alienes a l’Empresa Programadora. 6. La suspensió de la programació ja iniciada sempre que el termini de

suspensió sigui major de sis mesos. 7. Incompliment de les condicions del contracte quan implica mala fe. 8. Finalització del termini d’execució del programa sense haver arribat a

completar aquest. 9. Actuació de mala fe en l’execució dels treballs. 10. Subcontractar la totalitat o parts del programa a tercers sense l’autorització

del Tècnic Director i l’Empres Usuària.



5.2.8. Liquidació en el Cas de Rescissió del Contracte

Sempre que es rescindeixi el contracte per les causes anteriors o bé per acords entre les dos parts, s’abonarà a l’Empresa Programadora les unitats de programa ja acabades.

Quan es rescindeixi el contracte portarà implícit la retenció de la fiança per obtenir les possibles despeses de conservació en el període de garantia i els derivats del manteniment fins la data de la nova adjudicació.

5.3. Conclusions

Les parts interessades manifesten que coneixen els terminis d’aquest plec de condicions i el projecte tècnic que s’adjunta.

Les condicions contractuals que puguin existir entre l’empresa de serveis informàtics Getronics i els seus clients són confidencials. Per tal de complimentar aquest apartat del projecte s’ha realitzat un plec de condicions estàndard per aquests tipus de projecte informàtics.



Signat:



Bibliografia

6. Bibliografia.

Índex Índex.................................................................................................................. 1

6.1. Bibliografia............................................................................................................ 2 6.1.1. Llibres sobre programació ................................................................................ 2 6.1.2. Llibres sobre comerç electrònic ........................................................................ 2 6.1.3. Adreces d’internet.............................................................................................. 3

Bibliografia 1

6. Bibliografia.

6.1. Bibliografia

Durant la realització d’aquest projecte s’han anat recollint de manera acurada les fonts consultades, tant a nivell bibliogràfic com pàgines webs d’internet.

6.1.1. Llibres sobre programació

Títol : DB2: The Complete Reference. Autor : Roman B. Melnyk; Paul C. Zikopoulos. Editorial : McGraw-Hill. 2001. Títol : MVS JCL. Autor : Doug Lowe. Editorial : Mike Murach & Associates. 1994. Títol : PL/I Programmer’s Guide. Editorial : Wiley. 1991.

6.1.2. Llibres sobre comerç electrònic

Títol : Comercio Electronico. Autor : Gonzáles López, Óscar Rodrigo. Editorial : Anaya. 2002. Títol : Medios de Pago. Autor : García García, Juan José; Cornejo Pablos, José Fernando. Editorial : Fundació Confemetal. 2003.

Bibliografia 2

6. Bibliografia.

6.1.3. Adreces d’internet

http://www.ncr.com Pàgina web d’una de les moltes empreses dedicades a la fabricació de caixers automàtics. http://www.ibm.com/es Pàgina web oficial de la casa IBM.

http://www.visa.es Pàgina web oficial de Visa Internacional a Espanya.

http://www.sermepa.es/ Empresa dedicada als mitjans de pagament.

http://www.mastercard.com Pàgina web oficial de Mastercard Internacional.

http://www.4b.es Pàgina web oficial de la xarxa de caixers 4B.

http://www.euro6000.es Pàgina web oficial de la xarxa Euro6000.

http://www.servired.es Pàgina web oficial de la xarxa Servired

http://www.ceca.es Pàgina web oficial de la Confederació Espanyola de Caixes d’Estalvi.

Bibliografia 3

Aplicatiu de gestió d’incidències en

Comerç Electrònic

Annexes

AUTOR: Pere Ferrer Casaoliva .

DIRECTOR: Enric Vidal Idiarte .

DATA: Setembre / 2004.

Índex Annexes

ÍNDEX ANNEXES ANNEX I: MANUAL PROGRAMACIÓ PLI. ANNEX II: MANUAL PROGRAMACIÓ JCL. ANNEX III: MANUAL IMS. ANNEX IV: MANUAL EINA CASE - CONFIDENCIAL ANNEX V: TARGETES MAGNETIQUES BANCARIES.

Índex Annex 1

Manual Programació PLI

Annex I

Manual PLI

Índex Índex.................................................................................................................. 1 Programació en PL/I.......................................................................................... 2

1.1. Algorítmica............................................................................................................ 2 1.2. Estructures Bàsiques.............................................................................................. 2

1.2.1. Seqüencial: ........................................................................................................ 2 1.2.2. Condicional: ...................................................................................................... 2 1.2.3. Condicional Múltiple: ....................................................................................... 3 1.2.4. Iteracions:.......................................................................................................... 3

1.3. S’ha de Tenir en Compte ....................................................................................... 4 1.4. PL/I ........................................................................................................................ 4 1.5. Declaració del Programa ....................................................................................... 5 1.6. Blocs del Programa................................................................................................ 5 1.7. Tipus de Dades ...................................................................................................... 5

1.7.1. Numèrics............................................................................................................ 5 1.7.2. No Numèriques .................................................................................................. 6

1.8. Estructures ............................................................................................................. 7 1.9. Assignacions.......................................................................................................... 7 1.10. Operador ................................................................................................................ 7 1.11. Codificació de Condicions .................................................................................... 8

1.11.1. IF ................................................................................................................... 8 1.11.2. SELECT. ........................................................................................................ 8

1.12. Condicions d’Iteracions......................................................................................... 9 1.12.1. DO WHILE .................................................................................................... 9 1.12.2. DO TO ......................................................................................................... 10 1.12.3. DO UNTIL ................................................................................................... 10

1.13. Crida de Procediments i Funcions ....................................................................... 10 1.14. Sentències en PL/I ............................................................................................... 11 1.15. Compilació i Execució de Programes en PL/I..................................................... 11 1.16. Ordre de declaracions: ......................................................................................... 14

Manual PLI 1

Manual PLI

Programació en PL/I

1.1. Algorítmica

• Procés inicials: Obrir fitxer. Inicialitzar variables.

• Procés principals: Iteracions ( o while). Procediments i funcions.

• Procés Final: Escriure estadística. Tancar fitxer.

Construir sempre codís de retorno en PL/I.

1.2. Estructures Bàsiques

1.2.1. Seqüencial:

Inici Sentència 1 ....... Sentència n

Fi;

1.2.2. Condicional:

Si condició llavors Sentència 1 Sentència 2 ...... Sentència n

Sinó Sentència 1 Sentència 2 ...... Sentència n Fi ;

Manual PLI 2

Manual PLI

1.2.3. Condicional Múltiple:

Selecció (Variable) Quan (valor 1)

Sentència 1 Sentència 2 ...... Sentència n ......

Quan (Valor n) Sentència 1 Sentència 2 ...... Sentència n

En qualsevol altre cas Sentència 1 Sentència 2 ...... Sentència n

Fi de selecció;

1.2.4. Iteracions:

Des del valor 1 fins al valor màxim

Sentència 1 Sentència 2 ...... Sentència n

Fi iteració;

Mentre condició


Fi iteració;

Manual PLI 3

Manual PLI

Fer


Fins que no es compleixi la condició;

1.3. S’ha de Tenir en Compte

Si no es declaren les variables, el PL/I assigna per defecte unes característiques. S’ha de tenir en compte i declarar-les.

Al compilar, obtenim: SEVERE ERRORS WARNINGS ERRORS INFORMATORY ERRORS

Es en els INFORMATORY ERRORS on s’informen las variables no declarades.

En el cas de tenir varies condicions, es convenient ordenar-les segons l’importància, les més comuns en primer lloc,

Evitar conversions de variables.

No s’han de fer més lectures de fitxer que les necessàries.

1.4. PL/I

És un llenguatge molt potent per gestionar grans fitxers de dades.

Les instruccions han d’estar escrites entre les columnes 2 i 72.

Els comentaris es marquen així: /*...................*/.

Al compilar, si el resultat de la compilació dona un codi de retorn superior a 8 no serà executable.

Manual PLI 4

Manual PLI

1.5. Declaració del Programa

Primera Sentència:

NOM_PROGRAMA: PROC OPTIONS(MAIN) REODRER;

On el punt i coma és final de sentència i el REORDER optimitza la màquina, encara que no és imprescindible posar-ho.

1.6. Blocs del Programa NOM_PROGRAMA: PROC OPTIONS (MAIN); DECLARACIONS PROCES PRINCIPAL RUTINS I FUNCIONS END NOM_PROGRAMA;

1.7. Tipus de Dades

1.7.1. Numèrics

Segons: Mode (No el codifiquem perquè sempre treballem amb reals). Escala (Coma fixa o flotant) Base (Sistema decimal o binari) Precisió (Número de dígits per decimals. Decimals amb coma fixa o coma flotant)

No és necessari codificar-ho tot. S’ha de definir el mínim nombre de comes flotants. El mode no és necessari, treballarem amb reals, no amb complexos.

Declaracions. DCL NOM_VARIABLE DEC FIXED (7); ↑ ↑ ↑ Decimal Fix Posicions.

Manual PLI 5

Manual PLI

Les dades numèriques acostumen a estar empaquetades:

7 Posicions: xxxx En disc ocupen 4 posicions. xxxc 255450: 0540 255+ ← Signe + o – El número de posicions que ocupen és = (Dada Fixa + 1) / 2

Es sol reservar un número de posicions imparells, on es reservar una posició pel signe.

Normalment s’incialitzen les variables: DCL DATA_SYSIN BIN FIXED (7) INIT (0); ↑ S’inicialitza a cero.

Es pot definir un format de sortida imprès (PICTURE...).

1.7.2. No Numèriques

• CHAR

Es defineix la longitud que necessitem.

DCL PARM CHAR (80);

• PIC Lletres o números (Qualsevol tipus o caràcter).

• BIT Variables Boleanes, de tipus lògic (veritable o fals). DCL ERROR BIT(1) INIT(‘0’B);

Manual PLI 6

Manual PLI

1.8. Estructures DCL 1 DATA_SYSIN 5 DIA_AUX PIC ‘99’, 5 MES_AUX PIC ‘99’, ←Nivells Inferiors. 5 ANY_AUX PIC ‘99’; DCL TGAR135AI LIKE TGAR135; LIKE: Per declarar que són iguals a les estructures o declaracions.

INCLUDES: No fa falta definir els camps dels fitxers, ja estan definits a les includes.

DCL 1 TGAR135, % INCLUDE TGAR135; ← La va a buscar a la llibreria d’ includes.

1.9. Assignacions

VARIABLE A = VARIABLE B;

REG_ESBOR = REG_ESBOR + 1;

1.10. Operador & AND | OR ¬= DIFERENT

Manual PLI 7

Manual PLI

1.11. Codificació de Condicions

1.11.1. IF

IF Condició THEN Sentència (Si és solament una); DO; Sentència 1; Sentència 2; ← (Per més d’una sentència. Pot contenir solament una, .... però a les hores no són necessaris el DO i el END) Sentència n; END;

ELSE Sentència (Si és solament una); DO; Sentència 1; Sentència 2; ← (Per més d’una sentència. Pot contenir solament una, .... però a les hores no són necessaris el DO i el END) Sentència n; END;

L’instrucció IF, mai porta END final.

1.11.2. SELECT.

SELECT (Tipus de registre ); WHEN (Valor de tipus de registre 1)

DO; Sentència 1; Sentència 2; ← (Per més d’una sentència. Pot contenir solament una, .... però a les hores no són necessaris el DO i el END) Sentència n; END;

WHEN (Valor de tipus de registre 2) o WHEN (valor de tipus de registre 2, ..., n) DO; Sentència 1; Sentència 2; ← (Per més d’una sentència. Pot contenir solament una, .... però a les hores no són necessaris el DO i el END) Sentència n; END;

....

Manual PLI 8

Manual PLI

WHEN (Valor de tipus i registre n)

DO; Sentència 1; Sentència 2; ← (Per més d’una sentència. Pot contenir solament una, .... però a les hores no són necessaris el DO i el END) Sentència n; END;

OTHERWISE (Cap valor dels anteriors) DO; Sentència 1; Sentència 2; ← (Per més d’una sentència. Pot contenir solament una, .... però a les hores no són necessaris el DO i el END) Sentència n; END;

END;

S’ordena de més probable a menys probable.

1.12. Condicions d’Iteracions

1.12.1. DO WHILE

DO WHILE (Condició);

Sentència 1; Sentència 2; ← Sentències a realitzar .... Sentència n;

END;

Manual PLI 9

Manual PLI

1.12.2. DO TO

DO I=1 TO 10;


END;

1.12.3. DO UNTIL

DO UNTIL (Condició);


END;

1.13. Crida de Procediments i Funcions

CALL NOM_FUNCIÓ_ O_PROCEDIMIENT; Per definir procediments i/o funcions dintre del programa: NOM_FUNCIÓ_O_PROCEDIMIENT : PROC; Cos de la funció o procediment.

Es poden declarar variables internes (locals) del procediment o funció, que no podran ser cridades des de fora

END NOM_FUNCIÓ_O_PROCEDIMIENT;

Poden retornar un valor al programa quan són cridades per aquest. NOM_FUNCIÓ_O_PROCEDIMIENT:PROC RETURNS(DEC FIXED(3));

Manual PLI 10

Manual PLI

Cos de la funció o procediment. END NOM_FUNCIÓ_O_PROCEDIMIENT;

1.14. Sentències en PL/I

Les sentències habituals de PL/I es poden substituir per funcions reutilitzables.

Sentència PL/I

Funció Reutilizable

OPEN FILE ( NOM_FITXER)

STDWABRIR (NOM_FITXER)

READ FILE ( NOM_FITXER) INTO (REGISTRO)

STDWLEER(NOM_FITXER, INCLUDE)

WRITE FILE ( NOM_FITXER) FROM (REGISTRO)

STWGRAB(NOM_FITXER, INCLUDE)

CLOSE FILE ( NOM_FITXER) STDWCERR(NOM_FITXER)

1.15. Compilació i Execució de Programes en PL/I

Els programes PL/I els guardem en llibreries específiques de PL/I, i per la seva execució utilitzem jobs que tindrem guardats en altres llibreries específiques.

Exemple:

1. Declaració d’Estructures:

DCL ÀREA_ENTRADA CHAR (80);

DCL 1 PRÉSTEC BASED ( ADDR ( ÀREA_ENTRADA)), % INCLUDE REF_PRÉSTEC;;

DCL 1 REBUT BASED ( ADDR ( ÀREA_ENTRADA)), % INCLUDE REF_REBUT;; STDWLEER ( NOM_FITXER, ÀREA_ENTRADA );

Manual PLI 11

Manual PLI

2. Inicialització d’Estructures:

DCL 1 ESTRUCTURES_1, 3 CAMP_1 CHAR ( 2 ), 3 CAMP_2 PIC ‘( 3 )9’, 3 CAMP_3 FIXED ( 3 ); DCL ESTRUCTURA_2 LIKE ESTRUCTURA_1; ESTRUCTURA_2 = ‘ ‘; ← Inicialització de l’estructura alternativa. ESTRUCTURA_1 = ESTRUCTURA_2; ← Per inicialitzar estructura 1.

Aquest mètode estalvia CPU. També es poden utilitzar matrius i taules. Per inicialitzar variables numèriques: INIT(0); Per inicialitzar variables tipus CHAR: INIT(‘’); Existeixen dos maneres de realitzar assignacions:

ESTRUCTURA_A.CAMP1 = ESTRUCTURA_B.CAMP1; ESTRUCTURA_A.CAMP2 = ESTRUCTURA_B.CAMP2;

ESTRUCTURA_A = ESTRUCTURA_B BY NAME;

L’opció B s’utilitza únicament quan les dues tenen exactament la mateixa estructura i sabem que sempre serà així. Per una altra part, aquest mètode gasta molta CPU.

Manual PLI 12

Manual PLI

3. Tipus de Variables:

Per ordre de preferència és convenien utilitzar:

o BIN o DEC o PIC o CHAR o BIT, s’utilitza sempre que sigui estrictament necessari.

En operacions aritmètiques, és convenient:

o Tenir cura dels paràmetres. o Si no s’han d’utilitzar més de 15 dígits significatius, és convenient

utilitzar variables amb coma flotant (FLOAT). o És convenient evitar conversions de variables, però si és necessari s’ha

de fer amb cura ja que pot passar:

NUMÈRIC → CHAR (Poden haver canvis no desitjats) CHAR → NUMÈRIC (Error d’execució, sortint informats els Warnings)

Per evitar això és convenient utilitzar una variable intermitja, que es declara com a tipus PIC, i la conversió és realitzarà de la següent manera:

CHAR → PIC → NUMÈRIC

On la variable PIC la declarem basada a la variable CHAR, de la següent manera:

DCL VAR_CHAR CHAR ...; DCL VAR_PIC PIC ... BASED ( ADDR ( VAR_CHAR ) ) ; DCL VAR_NUM DEC FIXED ... ;

VAR_CHAR = ‘567’ ; VAR_NUM = VAR_PIC ;

Manual PLI 13

Manual PLI

1.16. Ordre de Declaracions:

• Constants (No és molt aconsellable la seva utilització)

• Macros de l’instal·lació:

STDI005, Copyrigh i nom del programa. STDI015, Funcions Batch. STDI014, Funcions Builtin PL/I, per tractaments numèrics, Multiply,

Divide ...

• Declaracions de fitxers amb les seves includes.

• Declaració de taules auxiliars, TAUX.

• Variables de treball.

• Models externs a declarar, que poden ser de dos tipus depenent com es processen en temps d’execució:

LINK, s’incorporen al compilar. (La majoria de components són

linkeditats). FETCH, no es busquen fins que no s’executen.

• IMS

LAN SISWDCL; Perquè existeixen rutines que utilitzen alguna dada del Frond End. A les hores és necessari fer les següents declaracions abans del final del programa. IMS...; LAN...; SISWGEN; Just abans del END final del programa.

• Condicions ONERROR, per tractar finals anormals o erronis.

• Rutines i procediments.

És important evitar molts IF encadenats, quan tinguem moltes condicions és preferible l’utilització d’una SELECT. I és important que sempre que utilitzem una SELECT, posem l’OTHER, per evitar possibles errors.

Manual PLI 14

Manual Programació JCL

Annex II

Manual JCL

Índex Índex.................................................................................................................. 1 2. Programació en JCL ................................................................................. 2

2.1. Introducció al JCL ................................................................................................. 2 2.2. Organització de Dades (Bàsiques a la Màquina)................................................... 3 2.3. Sintaxis de les Sentències Pròpies de JCL ............................................................ 5

2.3.1. Sentències .......................................................................................................... 6 2.3.1.1. JOB ............................................................................................................ 6 2.3.1.2. EXEC:........................................................................................................ 8 2.3.1.3. DD: ............................................................................................................ 9

2.4. Utilitats ................................................................................................................ 13 2.4.1. Normes de Codificació .................................................................................... 13 2.4.2. Utilitats ............................................................................................................ 14

2.4.2.1. IEFBR14.................................................................................................. 14 2.4.2.2. SISPTOOL .............................................................................................. 15 2.4.2.3. IEHLIST .................................................................................................. 15 2.4.2.4. IEBGENER ............................................................................................. 16 2.4.2.5. IEBCOPY ................................................................................................ 17 2.4.2.6. IEBCOMPR............................................................................................. 18 2.4.2.7. Concatenació ........................................................................................... 18 2.4.2.8. Referència Prèvia..................................................................................... 19

Manual JCL 1

Manual JCL

2. Programació en JCL

2.1. Introducció al JCL

JCL → JOB CONTROL LANGUAGE

És un llenguatge de baix nivell, no es compila, està molt proper al llenguatge màquina, és un llenguatge que controla l’execució del treball que enviem al sistema.

Necessita:

• Informació de comptabilitat. • Programes a executar. • Fitxers • Seqüència de procés i direcció. • Dispositius físics.

Sentències Bàsiques:

• JOB : Assigna nom al treball a executar i informació. • EXEC : Programes i utilitats a executar. • DD : Dades a emplenar per aquests programes.

En la línia de Command escriurem: SUBMIT o SUB que és l’instrucció que s’utilitza per enviar el JOB a executar.

Els procediments estan en llibreries PROCLIB, i no necessiten sentències JOB, té una sentència PROC.

Manual JCL 2

Manual JCL

JES

És el processardor de treballs del sistema operatiu. Tracta les sentències del treball des del principi fins al final.

1. Submit (TSO). 2. Entrada:

- ID (Número). - Comprovar comptabilitat. - Comprovar sentències JES.

Encua, Input i Output. Una vegada a la cua d’entrada 3. Conversió:

- Transformar el text del codi. - Comprovar sintaxis. - Comprovar si n’hi han crides a procediments, i si en troba les va a buscar a

les corresponents llibreries i les incorpora. 4. Execució. 5. Obtenim el resultat que va a una cua de sortida

2.2. Organització de Dades (Bàsiques a la Màquina)

Termes més comuns associats a les dades:

• Dades : Informació que donem a la màquina perquè la processi. • Registres : Grup de dades relacionades, per exemple, totes les dades d’un

mateix client. • Fitxer : Conjunt de registres. • Camp : Àrea o part específica d’alguna d’aquestes dades que hi ha dintre

d’un registre.

Manual JCL 3

Manual JCL

Tipus de Registres

Segons Longitud:

Fix : Longitud definida igual per tots. Variables : Es defineix la longitud màxima, però la longitud de cada registre és

variable.

Segons Treballi amb ells la Màquina:

Longitud : Registre definit per nosaltres al PL/I. Físic : Atenent a criteris de rendiment del sistema.

Esquemàticament:

Dada ↓

Lògic Lògic Lògic Lògic

Físic

En aquesta situació diem que els registres estan bloquejats, és convenient tenir-los així.

Organització de Dades

Seqüencial: Dades organitzades de manera seqüencial, tal com s’introdueixen s’han de llegir.

Fitxers Particionats: Llibreria d’un o més fitxers seqüencials, com poden

contindre més d’un, és necessari un directori a l’inici del fitxer on s’explicita la direcció i nom de cada fitxer seqüencial contingut.

Manual JCL 4

Manual JCL

Localització de fitxers, tenim dos maneres:

Nom + unitat + número de volum (Cada dispositiu físic de la màquina té un

número de volum). Catàleg: Si els fitxers estan catalogats, se li associa un nom de sistema. Aquest

nom queda associat amb l’ubicació física del fitxer.

Tenim diferents tipus i catàlegs, com a mínim.

Catàleg mestre:

Fitxers de sistema. Relació catàlegs i fitxers d’usuari.

Si està o no catalogat el fitxer, comporta una diferència en la manera de cridar el fitxer al JCL.

2.3. Sintaxis de les Sentències Pròpies de JCL

Exemple:

Identificador Nom Operació Paràmetres Comentaris // T5555XY JOB

EXEC DD

Paràmetres Comentaris

Per qualsevol sentència JCL

Màxim 8 caràcters. Primera posició alfabètic. Comença just a la tercera posició. Pot contenir caràcters numèrics, alfabètics y especials.

Sense espais i separats per comes.

Normalment no es posen camps i comentaris sinó línies, que començant amb //*.

Per posar línies de comentaris.

//*

Manual JCL 5

Manual JCL

Si una sentència ocupa més d’una línia (la longitud màxima d’una sentència és de 71 posicions), em de continuar escrivint a la següent línia a partir de la posició 4.

Paràmetres

• Posicionals: Els paràmetres tenen un ordre específic. Si s’omet algun, s’ha de substituir per una coma.

• Paraula Clau: Es posa després dels paràmetres posicionals i l’ordre entre ells és

indiferent.

2.3.1. Sentències

2.3.1.1. JOB

La sentència JOB s’ha de posar sempre, i és la que s’indica a l’inici d’un treball.

Els paràmetres posicionals són els que informen de la comptabilitat (TBSIS), i el nombre (Nom o cognom de la persona que ho ha fet).

Manual JCL 6

Manual JCL

Els paràmetres de paraules claus són bàsicament:

Paràmetre Valors Significat

CLASS C H J

Assigna el JOB a una classe de execució.

MSGCLASS V

Indica per on es veuran els missatges de sortida de l’execució.

NOTIFY T5555XY Identificador del receptor del missatge al acabar el procés.

MSGLEVEL Per seleccionar quin tipus de missatge volem tenir a la sortida (De tots els que s’han generat).

TYPRUN HOLD : Queda a la cua d’entrada preparada per l’execució esperant a ser avisada. SCAN : Verificar la sintaxis, no s’executa.

Especifiquem un tipus de procediment especial pel treball. Normalment no es posa.

TIME

Temps màxim d’execució. Temps màxim de CPU que volem que trigui.

RESTART RESTART = PAS3 Per rearrancar un job des d’un pas concret, quan aquest ha donat error o s’ha cancel·lat per algun motiu.

Manual JCL 7

Manual JCL

2.3.1.2. EXEC:

Defineix cada un dels passos a executar d’un job, pot contenir un màxim de 255 passos.

Té com a paràmetres posicionals el nom del programa o procediment que es crida perquè s’executi en aquest pas.

Sintaxis:

//PAS1 EXEC PGM = nom (Les referències sobre en quina llibreria es troben aquestes s’especifica posteriorment)

També té paràmetres de paraules claus per exemple PARM si el programa necessita dades per l’execució.

Un paràmetre molt útil és COND

Exemple: //ABEND011 EXEC PGM = IBMABEND, COND = ( 0, EQ , P010 )

El significat d’aquest codi indica que si el codi de retorn es igual a zero es salta aquest pas.

Nota: ( nº , Condició = ( EQ , LT , GT , GE ) , nº de pas )

Pot tenir condicions de diferents passos

Manual JCL 8

Manual JCL

2.3.1.3. DD:

És necessària al menys una sentència DD per cada fitxer que necessitem. Existeixen sentències DD que necessiten noms especials. Els paràmetres posicionals més comuns són:

• DATA, permeten incorporà sentències de control, es a dir, sentències no escrites al JCL.

• DUMMY, diem al sistema que treballem amb un fitxer fictici, útil per

realitzar proves. Els paràmetres de paraules claus són bàsicament:

Paràm. Valors Significat

DSN Nom físic del fitxer. &&Nom del fitxer, quan utilitzem un fitxer temporal per no sobrecarregar.

Indiquem al sistema el nom físic del nostre fitxer.

DISP 1. SHR : Mode compartit. OLD : Uso exclusiu. MOD : Ja existeix, però el modifiquem.NEW : Si el fitxer no existeix.

2. KEEP : El guardem. DELETE : L’eliminem. PASS : S’utilitza com fitxer temporal al acabar el job es borra. CATLG : El cataloga. UNCATLG : El descataloga.

3. Pot prendre els mateixos valors que en el cas anterior.

Per defecte se assumeix: DISP = ( NEW , KEEP , DELETE)

Estat o disposició del fitxer. Paràmetre obligatori sempre. Té tres subparàmetres, que per ordre indiquen: 1. Mode en que utilitzem el fitxer. 2. Que fer quan final OK. 3. Que fer quan final NOK.

Manual JCL 9

Manual JCL

SPACE

1. TRK : Pistes. CIL : Cilindres. Número de blocs (amb 5 dígits). 2. RLSE : Una vegada creat el fitxer es llibera l’espai sobrant.

Per sol·licitar espai al sistema. (‘1’,(‘2’,’3’,’4’)’5’) 1. Com anem a reservar l’espai.2. Espai primari que s’assigna

al crear el fitxer. 3. Espai secundari, que

s’utilitzarà quan l’espai primari estigui ocupat completament.

4. Espai reservat per crear el directori en fitxers particionats, si s’omet aquest subparámetre, és que es tracta d’un fitxer seqüencial.

5. Indica que fer amb l’espai sobrant.

UNIT - SYSALLDA o SYSDA: Dades en disc. - TAPE : S’indica quantes cintes necessitem (TAPE,01), s’utilitza per fitxers bastant grans. - TA80 : Per cartutxos, on les dos últimes xifres depenen del tipus de cartutx. - SYSWK : Per arxius petits. Es pot especificar un subparàmetre , DEFER, que indica que fins que no s’obri el fitxer no es muntaran els volums on s’anirà a guardar. Un altra subparàmetre que es pot utilitzar es AFF=DD1 (Pas 1) (Nom DD del primer fitxer), per indicar que es guarda on es va guardar el fitxer indicat en aquest pas.

Indica al sistema el tipus de dispositiu físic que anem a utilitzar per emmagatzemar les dades.

Manual JCL 10

Manual JCL

VOL S’indica el número i sèrie del disc en el

que es vol guardar, VOL = SER = nº de sèrie. Normalment es deixa que el sistema assigni el volum més convenient, VOL = . També es pot informar amb la referència perquè ho guardi on va guardar l’anterior fitxer, VOL = REF = nom del fitxer.

Indica un volum específic on es va a guardar el fitxer.

DCB (Data Control Block)

1. FB : Fix bloquejat. F Fix.

V Variable. VB Variable bloquejat. 2. S’indica el número de la longituds. 3. S’indica el tamany amb un dígit.

1. Tipus i registre, RECFM. 2. Longitud del registre,

LRECL. 3. Tamany del bloc, BLKSIZE. El factor de bloqueig és el número de registres lògics que hi ha dintre i un registro físic. Si la longitud del registre és 80, el tamany de bloc serà 80 * factor de bloqueig.

LABEL 1. Un número. 2. SL, Standard Label (Etiquetes

estàndards que proporciona IBM).

Quan treballem amb cintes o cartutxos, indica el número de cinta on residirà, té dos subparàmetres. 1. Posició relativa del fitxer a la

cinta. 2. Com s’ha gravat el fitxer a la

cinta.

SYSOUT

*, sortida estàndard que em predeterminat en el job amb el MSGCLASS=V.

Indica la sortida.

Manual JCL 11

Manual JCL

Amb la sentència DD tenim que economitzar el màxim. Depenent de l’estat del fitxer i el que volem fer amb ell, serà necessari definir uns paràmetres o altres.

Es pot donar tres passos fundamentals:

1) El fitxer existeix i està catalogat:

• El nom del fitxer, DSN.

• La disposició DISP. En aquest cas només és necessari el primer subparàmetre.

• La resta de l’informació que podem donar resultarà redundant.

2) El fitxer existeix i no esta catalogat:


• La disposició, DISP.

• El volum en el que es troba, VOL.

• Dispositiu en que està el fitxer, UNIT.

3) El fitxer no existeix i per lo tant no està catalogat:


• La disposició, DISP. Són necessaris tots els subparàmetres menys el primer, en el que posarem una coma ja que resulta innecessari.

• El volum en el que es troba, VOL.

• Dispositiu en que està el fitxer, UNIT.

• SPACE

• DCB.

Aquest són els paràmetres mínims per crear un fitxer.

Manual JCL 12

Manual JCL

2.4. Utilitats

Les més comuns són:

• IEFBR14. • SISPTOOL.

La resta: • IEHLIST. • IEBGENER. • IEBCOPY. • IEBCOMPR.

2.4.1. Normes de Codificació

Normes de codificació, de les sentències de control d’utilitats.

1) A la línia anterior a la sentència de control és necessària una sentència DD que es digui SYSIN, de manera que la línia justament anterior serà:

// SYSIN DD * (o DATA)

2) I a partir d’aquesta, tantes línies de control com siguin necessàries. 3) No comencen per doble barra //. 4) Es pot escriure fins la columna 71. 5) Si és necessari s’escriurà en més d’una línia.

a. S’interromp la sentència amb una coma. b. A la columna 72 es posa un caràcter, qualsevol. c. Continua la sentència a la columna 16 de la línia següent.

6) Per marcar el final de les sentències i control, s’escriu a la columna 1 i 2: /*

Manual JCL 13

Manual JCL

Algunes utilitats tenen sentències de control pròpies, que s’hauran de codificar.

Aquestes sentències de control es poden gravar en fitxers per no intercalar-les en el programa i han de guardar-se en fitxers amb longitud de registre de 80. Aquests fitxers poden ser tant seqüencials com particionats.

Si utilitzem un fitxer la crida es realitzarà:

// SYSIN DD DSNAME = Nom del fitxer.

2.4.2. Utilitats

2.4.2.1. IEFBR14

No necessita SYSPRINT, perquè no fa res, per lo tant no tenim que enviar missatges a cap part. Permet que s’activin els indicadors, i així poden crear-se fitxers des del job sense necessitat de fer-ho de manera interactiva des de fora (On-Line).

Exemple: //PAS1 EXEC PGM = IEFBR14 //O001 DD DSN = ... ← Definició del fitxer que creem, destruïm, etc. Útil per treballar amb fitxers. Permet crear, catalogar, etc.

Manual JCL 14

Manual JCL

2.4.2.2. SISPTOOL

Realitza copies entre fitxers seqüencials.

Exemple:

//P001 EXEC PGM = SISPTOOL //TOOLMSG DD SYSOUT = * ⎤ ← SYSPRINT propi. //DFSMSG DD SYSOUT = * ⎦ //I001 DD DSN = ... ← Fitxer d’entrada. //O001 DD DSN = ... ← Fitxer de sortida.

2.4.2.3. IEHLIST

Dona informació d’una columna, no pot llistar un catàleg, llista el directori d’un fitxer particionat, el VTOC d’un volum.

VTOC

El VTOC, conte entre altres informacions, els noms i direccions de cada un dels fitxers que conte el volum.

Sentències de control particular:

//P001 EXEC PGM = IEHLIST //SYSPRINT DD SYSOUT = * ← Perquè els missatges de l’utilitat es dirigeixin a la cua de sortida. //ANYNAME1 DD ...... ⎤ ← Tantes com informació de diferents volums //ANYNAME2 DD ...... ⎦ voguem. ...... Cada ANYNAME té necessàriament els paràmetres, UNIT, VOL DISP.

Manual JCL 15

Manual JCL

Amb la sentència de control pròpies:

- LISTVTOC, se llista el VTOC d’un volum, a l’índex. - LISTPDS, llista el directori d’un fitxer particionat.

S’ha de posar el DSNAME sencer, DSN no ho entén.

2.4.2.4. IEBGENER

Crea, copia o imprimeix fitxers particionats o seqüencials. Crea fitxers particionats a partir de seqüencials. Canvia o aplica dades d’un fitxer particionat.

Són necessàries dos sentències DD, una per fitxers d’entrada i una altra per fitxers de sortida.

//P001 EXEC PGM = IEBGENER //SYSPRINT DD SYSOUT = * ← Perquè els missatges de l’utilitat es dirigeixin a la cua de sortida. //SYSUT1 DD DSN = ... ← Fitxer d’entrada. //SYSUT2 DD DSN = ... ← Fitxer de sortida.

Especificat tant per fitxers d’entrada com per fitxers de sortida els paràmetres que siguin necessaris.

Sentències de control:

GENERATE

Si anem a crear un fitxer particionat.

GENERATE MAXNAME = n

Si anem a crear un fitxer particionat on n ens indica el número màxim de membres al fitxer particionat de sortida.

MEMBER NAME = ...

On s’indica el nom de cada un dels membres.

Manual JCL 16

Manual JCL

2.4.2.5. IEBCOPY

Útil per la gestió de fitxers particionats:

• Permet passar d’un fitxer particionat a un fitxer seqüencial, el que rep el nom de descàrrega.

• Fusió de diferents fitxers particionats. • Copiar un particionat sobre si mateix, per allibera espai.

Exemple:

//P001 EXEC PGM = IEBCOPY //SYSPRINT DD SYSOUT = * ← Perquè els missatges de l’utilitat es

dirigeixin a la sortida. //SYSUT1 DD DSN = ... ← Fitxer d’ entrada. //SYSUT2 DD DSN = ... ← Fitxer de sortida. //SYSIN DD* COPY OUTDD = SYSUT1 ← Sentència de control (Copy). INDD = SYSUT2 SELECT MEMBER = ( MEMBER1, MEMBER2, ... ) ← Selecciona membres del particionat a copiar. EXCLUDE MEMBER = ( MEMBER1, MEMBER2, ... ) ← Treu membres del particionat a copiar.

Si es vol realitzar amb tots els membres, simplement es posa la sentència COPY.

Per copiar en un arxiu que generem nosaltres: //I001 DD * (ó DATA) // (Text) o (Sentències de Control) /*

Manual JCL 17

Manual JCL

2.4.2.6. IEBCOMPR

Compara els continguts dels dos fitxers, tant particionats com seqüencials:

Exemple:

//P001 EXEC PGM = IEBCOMPR //SYSPRINT DD SYSOUT = * ← Perquè els missatges de la utilitat es dirigeixen a la cua de sortida. //SYSUT1 DD DSN = ... ← Fitxer d’entrada. //SYSUT2 DD DSN = ... ← Fitxers de sortida. //SYSIN DD* COMPARE TYPORG = PS ← Per fitxer seqüencial, assumeix això per defecte. PS ← Per fitxers particionats.

2.4.2.7. Concatenació

La concatenació de fitxers és l’agrupació de varis fitxers físics en un sol.

Normes de la Concatenació

Varis fitxers físics que s’agrupen en un únic nom lògic. Admeten un màxim de 255 fitxers si són seqüencials i 16 si són particionats. No es poden barrejar els fitxers seqüencials amb particionats, i han de tenir el mateix format de registre (RECFM). El tamany del bloc i la longitud dels registres no tenen perquè ser la mateixa, però s’ordenen de major a menor.

És necessari una fila DD per cada fitxer.

Sintaxis: //Nom DD ..... // DD ..... // DD .....

Manual JCL 18

Manual JCL

2.4.2.8. Referència Prèvia

S’utilitza per fer referències a fitxers anteriors.

Exemple: //PAS1 EXEC PGM = ..... //SORTIDA1 DD DSN =... ..... ..... //PAS50 EXEC .... //ENTRADA DD DSN = *PAS1.SORTI1 ← Això és una referència prèvia. .

Manual JCL 19

Manual IMS

Annex III

Manual IMS

Índex Índex.................................................................................................................. 1 3. IMS: Information Management System ................................................... 2

3.1. Introducció al IMS................................................................................................. 2 3.2. DBD (Database Description)................................................................................. 4

3.2.1. Checkpoint ......................................................................................................... 5 3.2.2. Restart................................................................................................................ 5 3.2.3. Paràmetre Restart ............................................................................................. 6 3.2.4. Paràmetres Checkpoint ..................................................................................... 6

3.3. PSB(Program Specification Block) ....................................................................... 7 3.4. PROBLEMES BMP (Errors IMS més usuals) .................................................... 10

Manual IMS 1

Manual IMS

3. IMS: Information Management System

3.1. Introducció al IMS

És un subsitema del sistema operatiu MVS (Multiple Virtual Storage)1. Serveix per facilitar la manipulació de les dades i la comunicació de les dades d’un lloc a un altra. Els seus components fundamentals són el DB (Data Based) i el DC (Data Comunication). Ens permet independència entre les dades i les aplicacions i a més a més un gran volum de procés amb resposta ràpida.

Sistema OperatiuMVS

IMS

Programa PGM

Podem estructurà l’IMS en les següents regions:

• Regions de Control, hi ha una sèrie de rutines pròpies de l’IMS que controlen els processos.

• Regions MPP, són parts de l’IMS on s’executen les transaccions i els processos On-Line.

• Regions BMP, són parts de l’IMS on s’executen els programes BMP (Batch Mesages Program), que accedeixen a bases de dades IMS, per això necessiten executar-se en una regió de l’IMS.

Batch, processos en diferit.

Batch Mínim, dintre del Batch, hi ha processos Batch que interactuen amb l’IMS

• Tancar l’Operativa. Durant una estona aquesta operativa no esta disponible per ningú.

• Actualitzacions massives de bases de dades. • Obrir l’Operativa.

1 Sistema operatiu introduït per IBM l’any 1974. Es tracta del sistema operatiu més utilitzat en els mainframes de IBM. Aquest sistema operatiu està orientat als processos Batch, amb una gran capacitat pel tractament de grans quantitats de memòria i grans espais de disc.

Manual IMS 2

Manual IMS

On-Line, sempre està a l’IMS

L’IMS serveix per controlar àrees de memòria, acceptar missatges d’entrada i distribuir missatges de sortida.

Actualment queden algunes reminiscències d’aplicacions antigues, que utilitzen bases de dades que s’executen mitjançant l’IMS (bases de dades DL/I). Ara totes les bases de dades noves es realitzen amb DB2.

Les bases de dades de l’IMS són jeràrquiques i la relació entre les dades és important. La estructura de la taula és similar a un arbre.

Esquema:

Nivell 1 Nivell 2

Nivell 3

Les bases de dades IMS són jeràrquiques. El número màxim de nivells que permet una base de dades IMS és de 15. Per accedir a les dades em de passar per tota la jerarquia. S’utilitza perquè l’accés a les dades és ràpid i permet treballar amb un gran volum d’informació. Les bases de dades més utilitzades per l’IMS són: DEDB (Data Extractor Data Based), MSDB (Mass Spectrometry Data Based) i HDAM (HD Data Based). Es diferencien per la forma que tenen per accedir a les dades. Per bases de dades petites utilitzarem DEDB i si són grans el HDAM. Per accedir a les dades ho fem a traves del protocol de fitxers VSAM (Virtual Storage Access Method). Les bases de dades MSDB s’utilitzen poc. Existeixen més tipus, per exemple els GSAM (Generalizes Sequencial Access Method).

Els fitxers GSAM són fitxers seqüencials que es tracten com si fossin bases de dades, ja que tenen un punter que pot reposicionar-se. Aquest tipus de fitxer ens permet coses que els fitxers seqüencials no ho permeten, per exemple, posicionar-se en qualsevol lloc del fitxer. No es podem utilitzar les sentències PL/I per tractar GSAM, per tractar aquests fitxers s’ha d’accedir mitjançant DL/I, amb les seves sentències pròpies.

Com a punter estàndard de l’IMS, s’utilitza TLPXIOP i és molt utilitzada la macro STDM010. Aquesta macro és molt útil perquè ens dona molta informació del programa quan dona un error.

Manual IMS 3

Manual IMS

Sentències Pròpies DL/I:

GET

INSERT

OPEN

CLOSE

3.2. DBD (Database Description)

Fan la definició de les bases de dades. És un membre d’una llibreria que ens explica com està definida una base de dades, com s’estructura i com s’organitza físicament.

Característiques de les bases de dades: Nom d’accés i depenent del tipus de dades, pot tenir una o més àrees.

DBD AREA = Nom_base_de_dades ACCESS = Tipus_acces

AREA DD1 = Nom_àrea ...... ......

SEGM AREA = ... PARENT = Nom_pare BYTES = ( long_màx, long_mín )

DBDGEN (Sentència per generar la DBD)

Els GSAM necessiten una DBD i les DBD es compilen.

Sempre que tinguem un segment de longitud variable, els dos primers dígits són per indicar la longitud.

Per fer un programa BMP (Batch Message Programa) necessitem compilar un programa, una PSB (Program Specification Block) i una DBD.

Manual IMS 4

Manual IMS

Nomenclatura d’un programa BMP:

FFEP600-799, la PSB i el PGM té el mateix nom.

Un BMP és un programa que es pot rearrencar des d’on ha donat l’error, permeten realitzar Checkpoints i Restarts.

3.2.1. Checkpoint

És un punt de sincronisme que es pren dintre d’un programa i serveix per:

• Poder determinar des d’on rearrencar. • Consolidació de canvis a bases de dades i alliberament de recursos.

És com un COMMIT de DB2 però amb més funcions. CALCKP_SIS és una variable que ens mira quan s’ha de fer un checkpoint, mira com de plens estan els buffers, quant de temps fa que no es realitza un checkpoint i mira quants registres em modificat (Aquestes tres coses abans es controlaven per separat)

IF CALCHKH_SIS = ‘1’ THEN

PRENDRE_CHECKPOINT;

3.2.2. Restart

Serveix per rearrencar i té una àrea amb la que emmagatzema l’últim registre llegit per poder rearrencar des de la posició correcte. El restart també permet el reposicionament.

Flux d’un programa BMP:

• Accions inicials, declaracions, obertura, inicialitzacions, ... • Restart. • Checkpoint (inici). • Cos principal del programa:

Do While ...

Accions ... Pren Checkpoint si la variable =’1’

End;

• Checkpoint (final ok).

Tant per prendre Checkpoints, com per fer un Restart s’ha de cridar a un mòdul SISMDLI.

Manual IMS 5

Manual IMS

3.2.3. Paràmetre Restart

RESTART: PROC; CALL SISMDLI ( NPAR6, XRST, TLPXIOP, MAXIMA, WRKREST, LLONG, AREACHKPT); IF TLPZIOP.PCCODES = ‘ ‘ THEN; ELSE

CALL TRATAR_ERROR....;

On els diferents paràmetres són:

• NPAR6, és el número de paràmetres que es van a introduir (En aquest cas 6). • XRST, funció que ha de fer. (En aquest cas un restart). • TLPXIOP, (Variable) nom del punter estàndard de l’IMS. • MAXIMA, longitud màxima de l’àrea d’entrada i sortida (del buffer) aquest

paràmetre és un BIN FIXED (31) • WRKREST, indica si estem fent un restart, rearrencant, o estem al

començament del programa. Si està al començament del programa ve a blancs, si no, ja té l’informació de la posició per rearrencar.

• LLONG, longitud de l’àrea de restart. L’àrea de restart, és on tenim l’informació de l’últim registre per rearrencar.

• AREACHKPT, àrea on es recuperen les dades.

3.2.4. Paràmetres Checkpoint

CHECKPOINT: PROC; CALL SISMDLI ( NPAR6, CHKP, TLPXIOP, MAXIMA, IDCHKPT, LLONG, AREACHKPT); IF TLPZIOP.PCCODES = ‘ ‘ THEN; ELSE CALL TRATAR_ERROR....;

Manual IMS 6

Manual IMS

On els diferents paràmetres són:

• NPAR6, és el número de paràmetres que es van a introduir (En aquest cas 6). • CHKP, funció que té que fer, en aquest cas un checkpoint. • TLPXIOP, (Variable) nom del punter estàndard de l’IMS. • MAXIMA, longitud màxima l’àrea d’entrada i sortida (del buffer) aquest

paràmetre és un BIN FIXED (31) • LLONG, longitud de l’àrea de restart. L’àrea de restart, és on tenim

l’informació de l’últim registre per rearrencar. • AREACHKPT, àrea on es recuperen les dades.

Els checkpoints tancant el cursor quan s’utilitzen, per lo tant quan es fan Checkpoints s’ha de declarar WITH HOLD FOR, perquè no es tanqui el cursor al realitzar el checkpoint.

DECLARE EL_CURSOR CURSOR WIUTH HOLD FOR ....

3.3. PSB(Program Specification Block)

Controla l’execució del programa BMP al que esta associat. Coses a fer:

• Seleccionar les bases de dades amb les que treballarà el programa. • Seleccionar els segments amb els que treballaran les bases de dades. • Operacions que farà el programa sobre les bases de dades.

PGM Font → PSB ( es compila ) → Objecte

Com estem treballant en versions, la PSB ha d’estar a la llibreria de la versió.

Manual IMS 7

Manual IMS

En una PSB l’estructura és:

• Una PCB (Program Control Block), que és el punter de la base de dades. A la PCB especifiquem:

o DSNAME, el nom de la base de dades. o TYPE, el tipus de base de dades. o PROCOPT, on indiquem les operacions a realitzar amb la base de dades i

aquestes poden ser:

A, all (fa tot). G, get (només llegir). R, replace (per modificar). D, delete (per esborrar). L, load (una carrega d’un fitxer, com inserir). I, insert (per inserir).

o KEILEN, longitud de la clau concatenada més llarga, perquè reserva un àrea

d’aquesta longitud. o POS, posicionament de la base de dades, pot ser:

S, simple, que és lo més normal. M, múltiple, si la base de dades és DEDB amb més de dos segments

dependents.

• SENSEG, especifiquem el segment o segments als quals accedim i li posem el nom (NAME) i el pare (PARENT).

SENSEG AME = EICS009 Nom

PARENT = 0 Posició jeràrquiques SENSEG AME = EICS010

PARENT = EICS009 ......

• PSBGEN, per finalitzar qualsevol PSB, els paràmetres que té associats són:

o LANG, llenguatge en que està codificat. o PSBNAME, nom del programa font. o CMPAT = YES, paràmetres de control de l’IMS, sempre és així. o IOEROPN = 415, paràmetre de control de l’IMS, sempre és així

PSBGEN LANG = PL/I

PSBNAME = EICP625 CMPAT = YES IOEROPN = 415

Manual IMS 8

Manual IMS

Tenim tantes PCB’s com objectes IMS tinguem que tractar.

S’ha de compilar la PSB. Això genera un objecte que es guarda a la llibreria IMSTST.PSBLIB. Una PSB és única per cada programa, no es comporta normalment, si es tenen que compartir, es defineixen d’una manera especial que evita contencions.

Els objectes IMS, com PSB, transaccions, ..., s’han de definir abans d’executar el programa. Per veure si una PSB existeix posem ‘ /DIS PSB NOM_PSB ‘. Si el programa abenda moltes vegades la PSB es para i es té que posar en marxa per rearrencar-la posem ‘/STA PSB NOM_PSB’.

Passos per una PSB:

• Definició a l’IMS. • Generació des de MAESTRO. • Compilació. • Paquet Changeman per pujar a públic2.

Per generar un fitxer GSAM de sortida en un JOB, lo primer que s’ha de fer és catalogar el fitxer i després executar el programa. Això s’ha de fer així perquè el programa sigui rearrencable.

Un BMP s’executa mitjançant l’utilitat DFSRRDOO posant en primer lloc el programa i en segon lloc la PSB.

En un BMP, al començar el programa em d’indicar quins punters van a utilitzar les bases de dades, després del PROC i entre parèntesis. El primer en declarar sempre és TLPXIOP (Un punter es reconeix perquè en la seva quarta posició té una X), l’ordre en que es posen en el programa es indiferent, però l’ordre en el que està al programa és el mateix que el que tenim a la PSB.

Els fitxer GSAM porten una A en la quarta posició.

Quan fem un SISMDLI, per controlar a la sortida els possibles errors posem un mòdul STDX818 que ens diu més sobre ells.

Per fer crides al DL/I utilitzem la macro IMSWDLI. Per tant per fer qualsevol cosa amb el GSAM utilitzarem aquesta instrucció. Per exemple, per obrir farem:

IMSWDLI (OPEN; FFEX085)

2 Un vegada es finalitza el desenvolupament d’un projecte, es traspassen tots el components de l’entorn de proves a l’entorn de públic. Una vegada a públic, ja pot ser utilitzat pel client.

Manual IMS 9

Manual IMS

Cada vegada que fem una crida d’aquests, tindrem que preguntar pel codi de retorn que es guarda a ZCOD22, un CHAR (1). Si dona 0 és que ha anat bé.

Per gravar registres farem:

IMSWDLI (ISRT; FFEX085, Dades a gravar, , , GSAM).

3.4. PROBLEMES BMP (Errors IMS més usuals)

U0456, PSB parada, l’IMS la para perquè han hagut moltes execucions.

U0418, nom de PSB no definida.

U0102, no troba el job del checkpoint quan ha donat un error. Pot ser que no ho trobi perquè ha hagut un error i esta realitzant el restart en CPU’s diferents.

Manual IMS 10

Manual Eina CASE

Annex IV

Manual Eina CASE

Índex Índex.................................................................................................................. 1 4. Eina CASE:............................................................................................... 2

Manual Eina CASE 1

Manual Eina CASE

4. Eina CASE: CONFIDENCIAL

Aquesta part del projecte conté informació confidencial i no ha estat

publicada, per obtenir informació adreçar-se a:

Enric Vidal Idiarte Telèfon : 977 559 622 Fax : 977 559 605 E-mail : [email protected]

Manual Eina CASE 2

Targetes Magnètiques Bancàries

Annex V

Manual Targetes Bancàries

Índex Índex.................................................................................................................. 1 5. Targetes Magnètiques Bancàries .............................................................. 2

5.1. Presentació i objectius ........................................................................................... 2 5.2. Coneixements Previs ............................................................................................. 2 5.3. Abreviacions.......................................................................................................... 2 5.4. Introducció............................................................................................................. 3 5.5. Dades de la Targeta ............................................................................................... 3

5.5.1. Track 1............................................................................................................... 4 5.5.2. Track 2............................................................................................................... 7

5.6. Estructura del PAN................................................................................................ 8 5.7. Més sobre el CVV ............................................................................................... 10 5.8. Especificacions ISO-7811 .................................................................................. 11

Manual Targetes Bancàries 1


5. Targetes Magnètiques Bancàries

5.1. Presentació i objectius

L’objectiu d’aquest manual és donar unes nocions bàsiques sobre l’informació que contenen les targetes bancàries (Magnètiques). Tota l’informació que apareix en aquest manual és de caràcter públic i es pot trobar fàcilment per la xarxa.

Aquest manual es centrarà en el contingut de les targetes, sense entrar en profunditat en el procés de transacció que es realitza.

5.2. Coneixements Previs

En aquest manual no es detalla el funcionament de la tecnologia magnètica així com l’estàndard ISO de targetes de banda magnètica (definit a les normes ISO número 7810 i 7811) que dona lloc a la física de les targetes, al seu sistema i les característiques de gravació.

Les targetes magnètiques es basen en les anteriors dos normes i s’acaben de perfilar amb tres normes ISO més:

ISO-7813 ISO-7812 ISO-4909

Bàsicament, de totes aquestes normes ISO ens centrarem en la ISO-7811.

5.3. Abreviacions

Durant la lectura d’aquest manual poden aparèixer una sèrie d’abreviacions:

ES → End Sentinel. LRC → Longitudinal Redundancy Check. FS → Field Separator. SS → Start Sentinel. ISO → International Organization for Standardization. ATM → Automated Telles Machine (Caixer Automàtic). ISSUER → Entitat Bancària que emet la targeta. POS → Point Of Sale (Punt de venda). A Espanya se’ls anomena

TPV (Terminal Punt de venda).



5.4. Introducció

Les targetes magnètiques tenen al seu exterior una sèrie de dades visibles que també es troben codificades a la banda magnètica. Però la banda magnètica conte informació que no es troba a l’exterior. Bàsicament a l’exterior d’una targeta trobem el número de la targeta, la data de caducitat i el nom del titular.

El número de la targeta sol ser de 16 xifres i rep el nom de PAN (Primary Account Number).

Si es passa una targeta bancària per un lector de bandes magnètiques, l’informació que obtindríem vindria a ser:

%B4847025030377523^PEREZ PEREZ JUAN ^0412101162910000000003091744291?* ;4847025030377523=04121011629109100000?= ;Altres dades ...

5.5. Dades de la Targeta

Les normes ISO defineixen la possibilitat de tenir fins a 3 tracks o pistes en una targeta bancària, que venen a ser les tres línies de la figura anterior. La banda magnètica d’una targeta la podríem veure com tres fraccions d’una cinta de cassette posades en paral·lel i cada una amb la seva informació. Quan es passa la targeta pel lector s’estan llegint aquestes tres pistes i com a resultat s’obtenen tres línies de dades. La tercera pista pot no tenir informació, però com a mínim ha de portar informació el track1 i el track2.

El track 1 i el track 2 s’utilitzen per validacions de transaccions, en canvi el track 3 l’utilitza el banc o entitat que emet la targeta. Això significa que quan pagues amb una targeta, en principi el track 3 és transparent. L’informació important per validar la transacció està al track 1 i 2. En canvi, si vas al caixer de la teva entitat financera pot ser que realitzin una lectura o una gravació d’aquest tercer track. En definitiva, si es borres el track 3, en el 99,9% de les operacions que es realitzessin no tindríem cap problema. Per aquest motiu i degut a la seva poca utilització no descriurem el funcionament del track 3.



Les següents normes ISO s’encarreguen de definir el contingut dels tres tracks.

Track 1 / 2 ISO – 7816 Track 3 ISO – 4909 Varis ISO - 7812

A continuació es descriurà l’estructura dels diferents tracks.

5.5.1. Track 1


Dades Generals Longitud 79 caràcters Joc de caràcters ALPHA (Números i lletres) Densitat 210 bpi ISO 7813


%B4847025030377523^PEREZ PEREZ JUAN ^0412101162910000000003091744291?*


% B 4847025030377523 ^ PEREZ PEREZ JUAN ^ SS PAN FS Nom SS

0412 101 162910000000003091744291 ? * Data SC Discretionary Data ES Irc

Obtenim que les dades amb el fons blanc són fixes mentre que les dades que tenen el fons gris són variables. A continuació passem a descriure l’informació que tenim:

B → Una targeta bancària és un tipus de targeta ISO7811. Doncs bé, no existeix un únic format de codificació, el que veurem és un d’ells i és el format de codificació ‘B’. Aquest format sempre el trobarem si es tracta d’una targeta bancària.





Nom → Existeixen 26 caràcters destinats al nom. Com es pot observar l’estructura que segueix el camp és: “Cognom1_Cognom2_Nom” on els guions baixos són espais. També podem trobar moltes vegades que s’utilitza la barra per separar el segon cognom del nom “Gognom1_Cognom2/Nom”. Si el nom té menys de 26 caràcters, s’acaba d’omplir aquest camp amb espais. Si conte més de 26 caràcters es talla el contingut per la dreta (Comença tallant o eliminant el nom). Com a curiositat, comentar que aquest camp pot no estar exactament igual a la banda magnètica que a l’exterior de la targeta. Ens podem trobar sobretot abreviatures per tal de donar cabuda al nom. Per exemple, podem trobar “J.Juan Perez Perez” i a la banda magnètica tenir “Perez Perez/José Juan “, o a la inversa. En resum, el nom que podem trobar a la banda magnètica no té perquè coincidir amb el nom que està estampat al plàstic de la targeta.

Data de caducitat → Són sempre 4 dígits i el seu format és AA/MM. És a dir, els dos primer dígits per l’any i els següents pel mes (la nostra targeta d’exemple caduca al desembre del 2004). A la banda magnètica trobem la data de caducitat al rebés de com està imprès al plàstic de la targeta.

SC (Service Code) → Aquests tres dígits defineixen les condicions d’utilització d’una targeta. Cada dígit té un significat i 10 possibles valors (0-9).

Dígit 1 Dígit 2 Dígit 3 Transacció Tecnologia Autorització Serveis Req. PIN 0 Normal Sense restriccions Es requereix PIN 1 Internacional Sense restriccions 2 Internacional SmarCard Issuer Només POS 3 Només ATM Es requereix PIN

4 Issuer menys

acords bilaterals

Només moneder electrònic

5 Nacional Només POS Es requereix PIN

6 Nacional SmarCard Sense restriccions PIN si existeix teclat

7 Privada Només POS PIN si existeix teclat

8 9 Test



Com podem veure a la taula anterior, el SC condiciona molt el procés de la transacció. A la pràctica això no és així ja que només es solen utilitzar a Espanya dos SC:

101 → Indica targeta de dèbit 121 → Indica targeta de crèdit.

Discretionary Data → També pot rebre el nom de “DD” o “DisData”. Ho podem definir com un conjunt de caràcters lliures. Qui codifica la targeta pot omplir aquests camps amb l’informació que cregui oportuna. Lògicament en aquest camp és on es troben els valors claus per validar un procés de transacció.

En el nostre exemple el valor de la DD és:

162910000000003091744291

A continuació passarem a explicar el significat d’alguns dels camps que apareixen al DD. Els cinc primes dígits que trobem reben el nom de PVV (Pin Verification Value) i permeten validar el PIN. A partir de diferents dades de la targeta el sistema realitza una sèrie d’operacions on el valor resultant ha de coincidir amb 6291. El Valor 6291 no és el PIN sinó el resultat d’una sèrie d’operacions complexes per validar que el PIN introduït sigui el correcte. El ‘1’ inicial és el PVKI (Pin Verification Key Indicator), que indica al sistema quina clau utilitzar a l’hora de realitzar la validació.

L’utilitat principal del PVV és la validació Off-Line del PIN. En l’actualitat, les targetes solen dur aquest camp a 0 ja que normalment ja s’està fent sempre la validació del PIN On-Line.

Dins del DD podem identificar un altra valor anomenat CVV o CVC (“Card Verification Value” per les targetes Visa i “Card Validation Code” per les targetes MasterCard). El significat que té és el mateix per totes les targetes, només canvia el nom. Aquest valor ens serveix per validar que la targeta sigui bona i el procés de verificació és molt similar al que es realitza pel PVV. A partir d’una sèrie de valors de la targeta, es realitza una operació complexa i el resultat ha de ser el CVV per tal de que es consideri la targeta com a bona. A l’exemple que estem utilitzant tenim el valor del CVV a “091”.



5.5.2. Track 2


Dades Generals Longitud Caràcters Joc de caràcters BCD (Números) Densitat 75 bpi ISO 7813


;4847025030377523=04121011629109100000?=


; 4847025030377523 = 0412 101 1629109100000 ? = SS PAN FS Data SC Discretionary Data ES Irc

Obtenim que les dades amb el fons blanc són fixes mentre les dades que tenen el fons gris són variables. A continuació passem a descriure l’informació que tenim:



Data de caducitat → Són sempre 4 dígits i el seu format és AA/MM.

SC (Service Code) → Aquests tres dígits defineixen les condicions d’utilització d’una targeta.

Discretionary Data → Veiem que aquí és més fàcil diferenciar el CVV. Moltes vegades després del CVV està tot a zero i altres cops tenim informació. Una manera senzilla de localitzar aquest camp és comparar el track 1 amb el 2 fins trobar tres dígits consecutius iguals.



5.6. Estructura del PAN

La longitud del PAN més habitualment és de 16 dígits, tal com s’indica a la ISO-7812 (Les targetes Visa i MasterCard tenen aquesta longitud).

Si dividim el PAN en quatre parts.

4 84702 503037752 3 Indústria BIN Num. Targeta Check Dígit

Tenim que el primer dígit indica l’industria, ja que no només segueixen aquest estàndard les targetes de crèdit. Els diferents valors que pot tenir aquest dígit són:

0 Altres indústries. 1 Línies aèries. 2 Línies aèries i altres indústries. 3 Viatges i oci. 4 Indústria financera. 5 Indústria financera. 6 Indústria financera. 7 Petroli. 8 Telecomunicacions i salut. 9 Assignacions nacionals.

La següent part és el BIN (Bank Identification Number). Aquest número indica l’entitat financera que emet la targeta. Cada banc sol tenir varis BINs assignats. Tot i que estrictament el BIN són 5 números es sol considerar com a BIN els 6 primers dígits. Un banc o caixa d’estalvis sol comprar diferents BINs per diferenciar entre les seves targetes de crèdit o de dèbit o inclòs diferenciar diferents productes (Un visa clàssic sol tenir un BIN diferent a una Visa Or, encara que siguin del mateix Banc). A mode d’exemple podem veure una sèrie de BINs de diferents entitats Espanyoles.

450625 Caixa Madrid (Visa Clàssic) 454771 Caixa Catalunya (Visa Or) 460332 BBVA (Visa Electron) 484558 La Caixa (Visa Clàssic) 496626 La Caixa (Visa Or)



La següent taula ens indica els diferents rangs de BINs segons el tipus de targeta que podem trobar a l’actualitat. Al tractar-se d’una taula molt resumida , segurament no estaran representats tots els BINs que s’utilitzen, però el que es pretén mostrar és que una targeta que comenci per ‘4’ difícilment no serà un Visa. Una targeta que comenci per ’51-55’ bàsicament seran MasterCard i les que comencin amb un ‘3’ seran American Express.

Tipus Targeta Rang de BINs Visa 400000 – 499999 MasterCard 510000 – 559999

American Express 340000 – 349999 370000 – 379999

Novus Network 601100 – 601199

Diners Club 300000 – 305999 360000 – 369999 380000 – 389999

JCB Card 352800 - 358999

Desprès del BIN trobem un camp de 9 xifres on s’informa el número de la targeta. Aquest número ens permet diferenciar les diferents targetes que estan dins d’un mateix BIN.

Per últim tenim el dígit de control, que permet validar que el PAN sigui correcte. Quasi tots el aparell que llegeixen bandes magnètiques comproven aquest dígit de control. A partir del 15 primers números, aquest últim es genera aplicant una formula que es diu “Luhn” o “Mod-10” o “Modulus-10”. Aquesta formula es basa en l’assignació d’un pes específic a cada dígit tal i com es mostra a la següent taula.

Pes 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 Dígits 4 8 4 7 0 2 5 0 3 0 3 7 7 5 2 Productes 8 8 8 7 0 2 10 0 6 0 6 7 14 5 4 ‘XY’=’X’+’Y’ 8 8 8 7 0 2 1 0 6 0 6 7 5 5 4 Suma 8 + 8 + 8 + 7 + 0 + 2 + 1 + 0 + 6 + 0 + 6 + 7 + 5 + 5 + 4 = 67

Al valor 67 s’arriba seguint els següents passos:

1. Multipliquem cada número pel seu corresponent pes. 2. Si obtenim un valor d’una sola xifra, ho deixem igual. En canvi si el valor és de

dues xifres (10 o més) li sumem (12 = 1 + 2 = 3, 16 = 1 + 6 = 7 ...). 3. Sumem tots els resultats. Arribant així al valor que apareix a la taula d’exemple.

Una vegada obtenim el valor resultant, agafem el següent múltiple de 10 (en el nostre cas 70) i li retem el valor obtingut. El resultat de la resta és el dígit de control. En el nostre cas és el ‘3’ (70 - 67).



5.7. Més sobre el CVV

A parat del codi CVV que es troba gravat a la banda magnètica, existeix un CVV2. Aquest esta format per tes dígits i es pot trobar gravat a la part del darrera de la targeta entre banda magnètica i la signatura del titular. El CVV2 serveix per validar les transaccions no-presencials (bàsicament per Internet o per telèfon). Es tracta d’una mesura antifrau que, d’alguna manera, permet donar més garanties que la persona que està utilitzant la targeta, la té físicament en aquest moment. A més a més, permet realitzar validacions sobre el PAN i la data de caducitat.



5.8. Especificacions ISO-7811

En aquestes especificacions trobarem tota l’informació sobre bandes magnètiques que ens facilita la norma ISO-7811. Podem trobar dades sobre els formats ISO-BCD / ISO-ALPHA, requeriments de escriptura / gravació, conjunts de caràcters que s’utilitzen, etc.


aplicatiu de gestió d’incidències en comerç...

Documents