UNIVERSIDADE DO EXTREMO SUL CATARINENSE - UNESC

CURSO DE PS-GRADUAO ESPECIALIZAO EM BANCO DE DADOS

REGINALDO JOS DA ROSA

EDI - INTEGRAO COM FORNECEDORES DE LOGSTICA:

APLICADO EMPRESA ANJO TINTAS E SOLVENTES COM O ERP
MICROSIGA PROTHEUS

CRICIMA, JUNHO DE 2006.

REGINALDO JOS DA ROSA

EDI - INTEGRAO COM FORNECEDORES DE LOGSTICA:

APLICADO EMPRESA ANJO TINTAS E SOLVENTES COM O ERP
MICROSIGA PROTHEUS

Monografia apresentada Diretoria de Psgraduao da Universidade do Extremo Sul

Catarinense - UNESC, para a obteno do ttulo de
especialista em Banco de Dados.
Orientador: Prof. (MSc) Paulo Joo Martins.

CRICIMA, JUNHO DE 2006.

A Deus e a minha famlia.

AGRADECIMENTOS

Ao Prof. Paulo Joo Martins, pela ateno, orientao e apoio.

Aos amigos que colaboraram direta e indiretamente.
Aos pais pelo apoio e incentivo ao estudo.
A meu sogro e sogra por dedicao aos meus filhos quando eu precisava de
isolamento para elaborao do trabalho.
Agradecimentos especiais a minha esposa Michele, e meus filhos Marina e Vincius,
que tiveram pacincia em todo o decorrer do trabalho e me incentivaram nos
momentos em que mais precisava.

RESUMO

As empresas vm buscando alternativas para melhorar seu desempenho

diante de um mercado globalizado, uma das formas utilizadas para isto o uso da
Internet como veculo de divulgao de informaes, e integrao com fornecedores.
Diante do exposto a empresa ANJO Tintas e Solventes pretende aumentar seu grau
de integrao com seus fornecedores no que se refere ao controle de frete de
venda. Para isto, esta utiliza o ERP Microsiga Protheus, e necessita de uma
integrao de sua base de dados com os fornecedores a fim de minimizar problemas
de consistncia de dados e melhorar a transparncia das informaes prestadas. A
integrao de base de dados no uma tarefa muito fcil e possui alto custo de
implantao agregado. Este trabalho se prope a encontrar uma soluo para
minimizar o problema de gerenciamento e controle dos fretes de venda, para a
empresa. Como a empresa j possui um ERP implantado, a soluo proposta foi
integrar os fornecedores de logstica, por meio de um website utilizando tecnologias
como Web Services (XML, DTD, SOAP, UDDI e WSDL) e EDI. Para isso, os
processos foram revisados e otimizados. Como resultado obteve-se um melhor
aproveitamento das informaes, tornando-a disponvel ao fornecedor e empresa
com maior agilidade e com menos interao humana, eliminando a necessidade de
digitao de documentos para ambos. Alm de reduzir custos e otimizar o processo,
tambm melhorou o gerenciamento sobre os valores do fretes pagos e minimizou o
trabalho por erros de lanamentos.
Palavras-chave: EDI. Web Services. XML. Integrao de base de dados. ERP.

ABSTRACT

The companies are searching for alternative to ahead improve its

performance of a global market, one of the forms used for that is the use of the
Internet as vehicle of spreading of information, and integration with suppliers. Ahead
of displayed the company Anjo Tintas e Solventes intends to increase its level of
integration with its suppliers as for the control of freight of sale. For this the company
uses the ERP Microsiga Protheus, and needs an integration of its database with the
suppliers in order to reduce problems of consistency of data and to improve the
transparency of the given information. The database integration is not a very easy
task and has a high cost of aggregate implantation. This work considers finding a
solution to reduce the problem of management and control of the freights of sale, for
the company. As the company has already an implanted ERP, the solution proposal
was to integrate the suppliers of logistic, by a website using technologies like Web
Services (XML, DTD, SOAP, UDDI and WSDL) and EDI. For this, the processes had
been revised and optimized. As result they got a better exploitation of the information,
becoming it available for the supplier and the company with more agility and less
human interaction, eliminating the necessity of manual work for both. Beyond
reducing costs and optimizing the process, also improved the management on the
values of the paid freights and minimized the work because of launchings errors.
Word-Keys: EDI. Web Services. XML. Integration Data-Base. ERP.

LISTA DE ILUSTRAES

Figura 01 - Fluxo dos dados na arquitetura Web Service .........................................28

Figura 02 - Arquitetura bsica de Web Services. ......................................................31
Figura 03 - Protocolos de comunicao de Web Services ........................................32
Figura 04 - Camadas do SOAP.................................................................................41
Figura 05 - Estrutura de um envelope SOAP ............................................................44
Figura 06 - Converso dos tipos de dados................................................................45
Figura 07 - Usabilidade do documento WSDL ..........................................................48
Figura 08 - Esquema UDDI .......................................................................................50
Figura 09 - ERP acessado por Clientes e Fornecedores ..........................................51
Figura 10 - Portais integrando diferentes ERPs. .......................................................52
Figura 11 - Modelos de ERPs integrados diretamente..............................................52
Figura 12 - Relacionamento do banco de dados.......................................................63
Figura 13 - Fluxo do processo com sistemas integrados ..........................................79
Figura 14 - Fluxo para o processo com sistemas no integrado ...............................80

LISTA DE QUADROS

Quadro 01 - Soluo de segurana...........................................................................24

Quadro 02 - Componentes do XML...........................................................................34
Quadro 03 - Exemplo de um documento XML ..........................................................35
Quadro 04 - Exemplo de declarao de DTD............................................................37
Quadro 05 - Exemplo de uma DTD ...........................................................................39
Quadro 06 - Definio do Envelope SOAP ...............................................................42
Quadro 07 - Envelope SOAP:Body ...........................................................................43
Quadro 08 - Envelope SOAP:Header........................................................................43
Quadro 09 - Declarao de Tipo de dados SOAP.....................................................44

LISTA DE TABELAS

Tabela 01 - Caracteres especiais de definio de ordem e a freqncia dos

elementos..................................................................................................................38
Tabela 02 - Possibilidades para os atributos tipo tokens ..........................................39

LISTA DE SIGLAS

AMREC

Associao de Municpios da Regio Carbonfera

ANSI

American National Standards Institute

ARPA

Advanced Research and Projects Agency

ASCII

American Standard Code For Information Interchange

BI

Business Intelligence

BSC

Balanced Score-Card

B2B

Business-to-Business

B2C

Business-to-Commerce

CIF

Cost, Insurance and Freight

CNPJ

Cadastro Nacional de Pessoa Jurdica

CORBA

Common Object Request Broker Architecture

CRM

Customer Relationship Management

DCOM

Distributed Component Object Model Protocol

DISA

Data Interchange Standards Association

DTD

Document Type Definition

DW

Data Warehouse

EAD

Educao a Distncia

EDI

Electronic Data Interchange

ERP

Enterprise Resource Planning

FTP

File Transfer Protocol

HTML

HyperText Markup Language

HTTP

Hypertext Transfer Protocol

IP

Internet Protocol

IRC

Internet Relay Chat

ISO

International Standards Organization

LAN

Local area Network

MRP

Material Requirement Planning

OASIS

Online Access To Services, Information And Support

POP3

Post Office Protocol 3

RH

Recursos Humanos

RPC

Remote Procedure Call

SAML

Security Assertion Markup Language

SGML

Standard Generalized Markup Language

SI

Sistemas de Informao

SMTP

Simple Mail Transfer Protocol

SOAP

Simple Object Access Protocol

SQL

Structured Query Language

SSL

Secure Socket Layer

TCP/IP

Transmission Control Protocol / Internet Protocol

TI

Tecnologia da Informao

TXT

Extenso de arquivo texto

UDDI

Universal Discovery, Description And Integration

UM/EDIFACT

United Nations Electronic Data Interchange for Administration,

Commerce and Transport

URL

Uniform Resource Locators

XML

eXtensible Markup Language

WSDL

Web Service Description Language

WS-SECURITY

Web Service Security

WWW

World Wide Web

W3C

World Wide Web Consortium

SUMRIO

1 INTRODUO .......................................................................................................13
1.1 Delimitao ......................................................................................................14
1.2 A empresa .......................................................................................................14
1.3 Problema .........................................................................................................15
1.4 Objetivos..........................................................................................................16
1.4.1 Objetivo Geral .................................................................................................................................... 16
1.4.2 Objetivo Especfico ............................................................................................................................. 16

1.5 Justificativa ......................................................................................................16

1.6 Estado da Arte .................................................................................................17
2 REVISO BIBLIOGRFICA..................................................................................19
2.1 Princpios fundamentais para um portal Web ..................................................19
2.1.1 Internet................................................................................................................................................ 19
2.1.2 Intranet e Extranet .............................................................................................................................. 21

2.2 Segurana da informao................................................................................22

2.3 Web services ...................................................................................................25
2.3.1 Padronizao ...................................................................................................................................... 26
2.3.2 Arquitetura dos WEB SERVICES ....................................................................................................... 27
2.3.3 Justificando os Web Services .............................................................................................................. 32

2.4 eXtensible Markup Language (XML) ...............................................................33

2.5 Document Type Definitions (DTD) ...................................................................35
2.6 Simple Object Access Protocol (SOAP)...........................................................40
2.6.1 Gramtica SOAP ................................................................................................................................ 42

2.7 Web Service Description Language (WSDL) ...................................................45

2.8 Universal Discovery, Description and Integration (UDDI) ................................48
2.9 ERP .................................................................................................................50
2.9.1 Tecnologias aplicadas no Microsiga Protheus. .................................................................................. 54

2.10 e-Business .....................................................................................................56

2.11 EDI.................................................................................................................57
3 INTEGRAO DE FORNECEDORES UTILIZANDO WEB SERVICES ...............59
3.1. Descrio dos problemas ...............................................................................60
3.2. Definio do escopo do projeto ......................................................................61
3.3 Detalhamento do banco de dados e dos processos ........................................62
3.3. Definio do layout dos arquivos ....................................................................65

3.3.1 Arquivo de envio das notas para os fornecedores .............................................................................. 65

3.3.1.1 Layout no formato TXT.................................................................................................................................65
3.3.1.2 Layout no formato XML ...............................................................................................................................67

3.3.2 Arquivo dos conhecimentos e das faturas emitidas pelo fornecedor .................................................. 70
3.3.2.1 Layout no formato TXT.................................................................................................................................71
3.3.2.2 Layout no formato XML ...............................................................................................................................74

3.4 Definio dos dados disponveis na Internet para os fornecedores.................78

3.4.1 Estrutura do portal para o fornecedor................................................................................................ 78
3.4.2 Fluxo do processo com sistemas integrados ....................................................................................... 79
3.4.3 Fluxo do processo com sistemas no integrados ................................................................................ 80
3.4.1 Definio das opes do portal .......................................................................................................... 81

3.5 Definio do web service integrado ao ERP Microsiga Protheus ....................82

3.5.1 Detalhes dos Web Services ................................................................................................................. 84
3.5.2 Exemplo de um servio de web service em ADVPL ............................................................................ 86
3.5.3 Documento WSDL............................................................................................................................... 89
3.5.4 Exemplo de um cliente de web service em ADVPL ............................................................................. 91

4 Concluso .............................................................................................................96
REFERNCIAS.........................................................................................................98
Referncias Complementares ..............................................................................100
APNDICES ...........................................................................................................101
APNCIDE A Tela de login do portal................................................................101
APNCIDE B Tela de consulta cargas faturadas (opo Consulta de Cargas)102
APNDICE C Tela de solicitao do caminho e arquivo para integrao dos
conhecimentos (opo Validao) .......................................................................103
APNCIDE D Tela dos erros encontrados no arquivo (Opo Validao) .......104
APNCIDE E Tela de Integrao do arquivo validado e pronto para gerao
(opo Validao) ................................................................................................105
APNCIDE F Tela de integrao apresentando valor de frete fora dos
parmetros especificados (opo Validao) ......................................................106
APNCIDE G Tela de consulta de cargas ainda no faturadas (opo Consulta
Cargas) ................................................................................................................107
APNCIDE H Tela de consulta cargas para gerao do conhecimento manual
(opo Conhecimento de Frete) ..........................................................................108
APNCIDE I Tela de preenchimento dos dados do conhecimento e seleo das
notas fiscais (opo Conhecimento de Frete)......................................................109
APNCIDE J Formulrio aplicado na pesquisa (enviado por e-mail) ...............109
APNCIDE K Tabulao dos resultados da Pesquisa .....................................113

13

1 INTRODUO

Atualmente as empresas buscam incansavelmente formas de

otimizar seus lucros. Esta busca envolve todos os setores das empresas, e de
maneiras diferentes, como: reestruturaes internas, alteraes de frmulas de
produtos, implantao de novas tecnologias, otimizao dos processos
administrativos e produtivos.
Inmeras tecnologias foram desenvolvidas e outras redesenhadas
para atender estas necessidades, auxiliando-as a alcanar este objetivo.
Para este trabalho ser estudado um problema enfrentado pela
empresa Anjo Tintas e Solventes, e possivelmente em outras empresas com
diferentes reas de atuaes no mercado.
O problema estudado ser a dificuldade em gerenciar os fretes de
venda, cujas notas fiscais so expedidas na modalidade de frete CIF, no qual a
empresa assume o pagamento deste valor.

Devido ao grande volume de

conhecimentos de transportes que se acumulam no final do ms, sendo este

um gargalo no setor de recepo fiscal, assim possibilitando erros de
lanamento e dificuldade na a conferncia dos valores dos fretes.
A proposta para soluo mistura conceitos antigos com novas
tecnologias. Permitindo assim que a empresa e seus fornecedores de logstica
integrem seus sistemas para reduzir tempo e custo no processo de gerao e
gerenciamento dos conhecimentos de frete. Por meio de um website como
interface para integrao entre o ambiente do fornecedor com a empresa,
utilizando as tecnologias Web Service, XML e EDI, foi desenvolvido uma

14

soluo que atraia os fornecedores e venha a reduzir o problema para a

empresa. Assim aumenta o nvel de conferncia dos valores de fretes, reduz o
volume de trabalho para o setor de recepo fiscal, e ainda reduz custos para o
fornecedor com a possibilidade de uso dos dados disponibilizados via EDI.

1.1 Delimitao

Como base para o projeto ser utilizada a empresa Anjo Tintas e

Solventes. A mesma j possui o ERP (Microsiga Protheus 8.11) implantado, o
projeto utilizar a tecnologia disponvel nele para sua implementao.
Uma pesquisa ser realizada com os usurios do ERP Microsiga
Protheus na Regio da AMREC, com o intuito de avaliar o cenrio atual da
utilizao das tecnologias abordadas. Os usurios sero selecionados de forma
a no restringir um nico setor econmico da regio, mas uma amostragem de
todos os setores que a Microsiga atende nesta regio.

1.2 A empresa

A Anjo Tintas e Solventes uma empresa genuinamente brasileira,

e fundada em abril de 1986. Localizada na Rod. SC 447, km 2, no distrito de
Rio Maina, em Cricima (SC).
A empresa detentora da marca Anjo, e participa dos mercados
interno e externo nos segmentos de tintas, solventes e complementos, onde
conta com 4 linhas de atuaes, so elas: Linha Automotiva, Linha Imobiliria,
Linha de Impresso e Linha Industrial.

15

Atualmente, lder de mercado na maioria dos produtos que fabrica,

possuindo mais de 10.000 clientes cadastrados em todo o Brasil, o que a torna
uma das maiores e mais importantes empresas do mercado de tintas e
solventes.
Com a filosofia Buscar ser melhor a cada dia a Anjo Tintas e
Solventes uma empresa inovadora. Desde abril de 1999 certificada pela
Norma ISO 9002, que reconhece internacionalmente a qualidade dos produtos
e servios Anjo. Em 2002, foi recertificada com a Norma ISO 9001/Verso
2000.

1.3 Problema

Volume muito grande de conhecimentos de fretes de venda, gerando

possibilidade de ocorrerem erros de lanamentos.
O valor do frete s conhecido quando os conhecimentos chegam
empresa e so lanados no sistema.
O valor cobrado pelos fornecedores nem sempre confere com a
tabela de preo negociada com a empresa.

16

1.4 Objetivos

1.4.1 Objetivo Geral

Otimizar os processos de gerenciamento de frete de venda, por meio

da integrao com os fornecedores.

1.4.2 Objetivo Especfico

Minimizar os erros de lanamento de conhecimento de frete.

Integrar os fornecedores de servios de transporte.
Dar maior transparncia sobre os valores cobrados pelo servio e
que estes sejam os valores negociados previamente.

1.5 Justificativa

A necessidade de tornar os negcios cada vez mais gil, lucrativo e

agregar parceiros comerciais comprometidos com a empresa, propicia a rea
de TI um desafio que integrar todos os parceiros com a empresa de forma
prtica e eficiente.
Vimos que um dos fatores importantes para esta aproximao
Fornecedores x Empresa, comea pela disponibilidade de informao precisa,
atualizada e disponvel a qualquer hora e local.
Com as informaes j integradas internamente na base de dados
das empresas por meio da utilizao de sistemas ERPs. Para concretizar esta

17

almejada integrao com parceiros distantes fisicamente, ser apresentada

uma unio de tecnologias para obter a adeso por parte dos fornecedores. Aos
fornecedores que j esto bem estruturados ser disponibilizado o EDI em
formato XML ou TXT de largura fixa, tambm um analisador para o arquivo de
remessa. Aos fornecedores menos estruturados, ser disponibilizado por meio
de um portal com web services todos os servios necessrios para a
integrao ser realizada.
Como o projeto se basear no ERP Microsiga Protheus, sero
abordados alguns recursos implementados pelo fornecedor para criao de
web services utilizando ferramentas prprias e integradas ao ERP.

1.6 Estado da Arte

Pode-se constatar que Web Services j uma realidade, empresas

como a Google esto disponibilizando servios de buscas para quem se
interessar a usar. Algumas outras j esto usando freqentemente, como os
sites de venda como Submarino e Amazon.
O Microsoft MapPoint.NET, est disponibilizando no seu site uma
interface Web Service para os programadores utilizarem, como os Commom
Service, Find Service, Rendere Service, Route Service entre outros (POTTS,
2003).
Fabiane

Bizinella

Nardon,

da

unidade

de

pesquisa

desenvolvimento do Instituto do Corao do Hospital das Clnicas da

Faculdade de Medicina da USP, analisou e criou uma representao

18

estruturada em XML para informaes de pacientes. Algo muito difcil de

realizar, devido natureza da informao.
Conforme o consultor de tecnologia aplicada Nestor Garcia da
empresa TechnoReport, pode-se realizar a integrao entre sistemas legados e
as novas tecnologias que surgem a todo o momento.
Segundo GALVIN (2004), pode-se utilizar Web Service para
desenvolver um sistema Customer Relationship Management (CRM) para
dispositivos mveis principalmente para usurios focados no atendimento a
clientes, citando como exemplo para vendedores e representantes.
A fornecedora dos handheld PALM em seu White paper (Integrating
Mobile Data Services into Enterprise Infrastructures) apresenta soluo
utilizando seus dispositivos mveis como cliente de um web service de
informaes mdicas de emergncia.
A discusso sobre essa tecnologia est apenas no comeo, muitas
coisas sero exploradas, principalmente na rea que diz respeito segurana
e comunicao com banco de dados.
No artigo Comportamento Ativo em Web services, escrito por Marcel
Felipe Weschenfelder, Daniela Leal Musa, Jos Palazzo M. de Oliveira,
descreve como a utilizao de Web Service foi implementada para solucionar o
monitoramento de eventos ativos e totalmente gerenciveis em um sistema de
EAD (Aplicao de ensino a distncia), o Caroline. Por intermdio do Web
Service o cliente (no caso o aluno) recebe informao em tempo hbil sobre
um agendamento realizado pelo fornecedor (no caso o professor) sem a
necessidade de acessar o sistema EAD para pesquisar possveis alteraes de
datas efetuadas pelo professor.

19

2 REVISO BIBLIOGRFICA

2.1 Princpios fundamentais para um portal Web

Com o advento da Internet, as distncias foram encurtando, as

fronteiras para a comunicao entre fornecedores e clientes, agora limitasse a
um toque no teclado. As empresas iniciaram uma verdadeira revoluo nos
processos burocrticos. Novos negcios formaram-se e outros foram
aperfeioados.
Franco Jr (2001, p.17), comenta a compra de produtos e servios
pela Internet est causando enorme revoluo no mundo dos negcios e na
vida dos consumidores.
Sero apresentadas as tecnologias que permitem que os processos
das empresas sejam revistos, nos captulos que se seguem.

2.1.1 Internet

A Internet derivada da rede militar ARPANET criada nos anos 60

pela agncia do departamento de defesa americano, ARPA (Advanced
Research Projects Agency). Projetada para continuar funcionando mesmo que
parte dela sofra um colapso, tornou-se uma rede de comunicao segura.
Vrios servios so disponibilizados pela rede, devido utilizao da
pilha TCP/IP (Transmission Control Protocol/Internet Protocol). Hoje, grande
volume de transmisso de dados da Internet se baseia neste protocolo, que na

20

realidade so dois, o TCP e o IP. O TCP/IP formado ainda por um conjunto

de outros protocolos, cada qual com funo especfica, tais como: POP3 e
SMTP para envio e recebimento de mensagem (e-mail), o IRC para bate-papo
(Chat), o HTTP para transferncias de hipertextos e o FTP para transferncia
de arquivos, dentre outros no citados.
Devido ao grande sucesso obtido, e pela exploso do nmero de
pginas publicadas, e da simplicidade de navegao permitida pelo protocolo
HTTP, fizeram com que muitos confundissem a Internet com WWW, mas este
somente um dos protocolos que a Internet oferece.
Para Franco Jr (2001, p.17), a Internet e World Wide Web (novo)
so dois conceitos distintos que geralmente so confundidos. Ambos referemse a redes de comunicao.
Segundo Albertin (2002, p. 42), a Internet (Intercontinental
Networks) um sistema de distribuio de informao espalhado em vrios
pases.
Idealizada com objetivos estratgico-militares em 1969, foi liberada
ao meio acadmico para fins restritos de pesquisa e educao no meio da
dcada de 80. Somente em 1993, sob muita presso poltica, foi aberta para os
negcios. Assim, a Internet com seus servios bsicos, tais como e-mail e
www, tm criado um novo espao para a realizao de negcios. Fornecendo
canais alternativos para troca de informao, comunicao e distribuio de
diferentes tipos de produtos e servios, alm de iniciar transaes comerciais.
Para Albertin (2002, p. 44), Assim, a Internet e o avano que ela
proporcionou mudaram os conceitos de tempo e espao, tanto em termos
sociais como empresariais.

21

Alm da Internet, ambos os autores mencionam as Intranets e

Extranets como peas importantes para o comrcio eletrnico.

2.1.2 Intranet e Extranet

Uma boa definio para Intranet a utilizao dos recursos e

protocolos da Internet em redes locais. Assim possvel com uma interface
simples e consolidada, para distribuir documentos e servios para os
colaboradores da empresa. As Intranets alm de disponibilizar documentos e
servios considerados pblicos dentro de uma corporao, tambm podem
conter contedo de acesso restrito. Para os usurios obterem acesso a estes
contedos, basta informar um login e uma senha previamente registrada no
gerenciador da Intranet.
Franco Jr (2001, p.18), discorre sobre Intranets como usando o
mesmo protocolo HTTP, baseado na navegao pela Internet, as Intranets so
redes similares www [...], no entanto com acesso de usurios restritos a uma
autorizao por parte do gerenciador da Intranet.
A grande vantagem da Intranet a possibilidade de disponibilizar
contedo a seus colaboradores, independentemente do local de acesso,
geograficamente distante com velocidade e segurana, como se estivesse em
seu ambiente de trabalho local.
A Extranet, tambm usa o protocolo da Internet, HTTP, sendo que
seu objetivo a troca de informao entre diferentes Intranets, isso com a
configurao e permisso necessria para este procedimento.

22

A Extranet caracteriza-se tambm por disponibilizar informaes a

qualquer usurio, que no faa parte do corpo de colaboradores da empresa,
em qualquer lugar do mundo, desde que autorizado previamente, tambm
utilizando login e senha. Ou seja, disponveis somente a um grupo de usurios
reconhecido pelo sistema, podendo ser clientes, fornecedores, entre outros.
Albertin (2002, p. 58), registra muitas empresas esto utilizando a
WWW para comunicar-se com seus clientes e fornecedores pela publicao de
contedo em seus servidores de WWW para uma distribuio em grande
escala.
Como as informaes comeam a atravessar as fronteiras da rede
local, a segurana da informao assunto para o prximo tpico.

2.2 Segurana da informao

No iremos tratar sobre a segurana da informao neste trabalho,

mas como sero abordados temas relativos transmisso de dados via
Internet, este tpico torna-se importante para esclarecimento sobre o assunto.
As transaes eletrnicas so uma realidade, e para que estas
transaes sejam realizadas, os usurios (clientes e fornecedores) tm que se
sentirem seguros. Alguns requisitos fundamentais de segurana para a
realizao de transaes eletrnicas so: Confiabilidade, Autenticao,
Integridade de dados, No repudio e Aplicao seletiva de servios.
Uma ameaa de segurana definida por Albertin (2002, p. 204)
como uma circunstncia, condio ou evento com potencial de causar danos

23

em dados ou recursos da rede na forma de destruio, revelao, modificao

de dados, negao de servio ou fraude, desperdcio e abuso.
Algumas das formas de providenciar segurana para as informaes
eletrnicas so: criptografia, assinatura digital, certificados digitais, firewall e
firebreak, dentre muitas outras.
A

criptografia

baseada

em

algoritmos

matemticos

que

embaralham as informaes antes de serem transmitidas e desembaralham

quando recebidas para tornarem legveis novamente aos usurios. A
Criptografia pode ser utilizada para criar um canal seguro de comunicao
sobre uma rede pblica, como na Internet.
As assinaturas digitais so utilizadas somente para validar a origem
e a integridade do contedo transmitido. Documentos assinados digitalmente
(assinatura adquirida junto a entidades certificadoras de renome, seguindo a
infra-estrutura do ICP-Brasil) tm validade como se o documento recebesse
uma assinatura de punho e registrada em cartrio.
O certificado digital uma declarao digitalmente assinada por uma
autoridade certificadora que permite a codificao e assinatura de mensagens
para assegurar a sua autenticidade, integridade e inviolabilidade muito
utilizadas em pginas comerciais na Internet.
A funo de um firewall criar uma barreira eletrnica com
hardware e software que protege o trfego da rede e validam o fluxo de
informao entre as redes internas e externas.
J o firebreak cria uma barreira fsica entre os servidores de Internet
e os sistemas de informao internos, para definir um nvel mais alto de
segurana, alm do fornecido pelo firewall.

24

Franco Jr (2001, p. 234), afirma que os sistemas de criptografia

provm um alto nvel de confiana, integridade e autenticidade da informao
que est trafegando pela Internet.
Albertin

(2002,

p.

207),

acrescenta

que

[...]

protegem

cuidadosamente seus sistemas internos com um firewall. Em alguns casos em

que requerida segurana em alto nvel, as empresas instalam firebreaks [...].
O quadro abaixo relaciona os problemas de segurana e privacidade
no ambiente digital atual, aspecto de negcio e a possvel soluo.
Problema
Autorizao

Autenticao

Integridade

Privacidade
Fraude / Furto
Sabotagem

Aspecto de Negcio
O usurio tem permisso de
acessar
o
computador
especfico ou o conjunto de
informaes?
O usurio verdadeiramente
quem ele diz ser?

A
pessoa
mandou
a
mensagem
realmente
enviada?
O destinatrio pode ter
certeza de que a mensagem
no foi alterada.
A converso, ou transao de
negcio privada?
Tem algum espionando:
Tem algum roubando?
Algum pode entrar no
sistema e destruir ou alterar
uma informao?

Soluo
Nome do usurio e senha, ou
outro tipo de mecanismo de
controle de acesso.
Sistema de hardware e
software especfico gera um
nmero randmico, o qual o
usurio
ir
usar
para
autenticar a integridade.
Assinatura digital

Algoritmo de criptografia de
chave pblica ou privada
Polticas e procedimentos de
gerenciamento de sistemas,
log e auditoria.
Firewalls e firebreaks

Quadro 01 - Soluo de segurana

Fonte: Adaptado de Albertin (2002, p. 222).

Para Potts (2003, p.292), o nvel de segurana necessrio relativo

ao valor da mensagem a ser transmitida. Um nmero de um carto de crdito
tem necessidade de um nvel de segurana muito maior que uma lista de seus
nomes de animais de estimao, por exemplo.

25

Como de conhecimento, sabe-se que uma mensagem trafegando

pela Internet pode ser capturada por qualquer pessoa com muita facilidade,
desde que se utilize software apropriado para este feito, tipo sniffers. Ou at
mesmo seus servidores sofrerem ataques (denominao dada a uma tentativa
de acesso no autorizado na Internet) para quebra de segurana.
Portanto, Potts (2003, p. 294) conclui que se os custos que voc
impuser forem mais altos do que o ganho de interceptar sua mensagem, voc
pode esperar, com razovel segurana, que o hacker simplesmente procure
outros alvos mais fceis.
O protocolo SSL (Secure Socket Layer) que capaz de proteger
uma mensagem durante o transporte, uma tentativa de tornar os sites mais
seguros. Porm Potts (2003, p. 298) afirma que o SSL, por si s, no pode
fornecer autenticao integridade de dados e no-rejeio durante a existncia
da mensagem se ela for roteada atravs de mais de um servidor Web.

2.3 Web services

Web Service mais uma evoluo tecnolgica, que uma revoluo

propriamente dita. Pois outras tecnologias tambm podem oferecer ao usurio
muito do que o web service oferece (CZERVENY, 2004, p. 51).
A

grande

promessa

dos

Web

Services

baseada

na

interoperabilidade, ou seja, toda aplicao de software no mundo pode se

comunicar com qualquer outra. Ultrapassando todas as antigas barreiras de
local, sistema operacional, linguagem, protocolo, entre outros.

26

Potts (2003, p. 3) define como Um Web Service uma aplicao de

software que pode ser acessada remotamente usando diferentes linguagens
baseadas em XML.
Os Web services se baseiam no envio de mensagens XML
(eXtensible Markup Language) em um formato SOAP (Simple Object Access
Protocol) especfico. Mas como a interoperabilidade dos Web Service seja
difcil de ser alcanada, as organizaes especificadoras buscam a definio
de padres para atingir esta meta.

2.3.1 Padronizao

Estes padres so teis, pois a indstria pode no aderir a projetos

criados por uma nica empresa, sendo que podem ficar atrelados a um nico
fornecedor, e se este no abrir o padro desenvolvido, a tecnologia pode no
evoluir e os investimentos escoarem pelo ralo. Por isso, os concorrentes se
unem na organizao das especificaes para criarem padres de consenso e
com maior probabilidade de obteno de credibilidade perante a indstria.
Dentre as principais organizaes especificadoras, a W3C (World Wide Web
Consortium) controla as especificaes SOAP, WSDL, XML, XML Schema e
HTTP e a OASIS (Organization for the Advancement of Structures Information
Standards) controla as especificaes UDDI, WS-Security e SAML.
Potts (2003, p. 284) registra, Se um padro demorar a ficar pronto,
os fornecedores de softwares implementaro suas prprias solues, tornando,
assim, mais difcil para que eles adotem o novo padro posteriormente.

27

Depois que estes padres so editados ou revisados e ento

publicados, os fornecedores de ferramentas as implementam em seus
produtos. A seguir uma relao de ferramentas para criao de Web Services,
mais conhecidas: Apache Axis, Java, Visual Studio.NET, Web Services.NET
Clients, BEA WebLogic WorkShop, IBM WebSphere Studio Application
Developer.
Potts (2003, p. 10), Com o inimigo a bordo, o crescente grupo de
apoiadores procura uma organizao especificadora, como W3C ou a AOSIS,
para administr-lo. [...], o comit publica a especificao e a chama de padro
(OASIS) ou de recomendao (W3C).

2.3.2 Arquitetura dos WEB SERVICES

Os Web Services so aplicaes de softwares que pode ser

acessada remotamente, usando XML na sua estrutura de programao.
Geralmente so identificados por uma Uniform Resouce Locator
(URL)1, como qualquer pgina da Internet. A diferena est no contedo do
que enviado na requisio do cliente para servidor (POTTS, 2003, p. 4).
Um web service um conjunto de funes que podem ser invocados
atravs da rede, utilizando o protocolo SOAP. Estas funes recebem o nome
de web methods. Eles permitem que dois programas se comuniquem de uma
maneira tecnicamente muito semelhante invocao de pginas Web.
Web services promete realizar com o SOAP, que clientes e
servidores heterogneos possam compartilhar aplicaes usando mdulos que

Especifica o endereo de um objeto no Internet.

28

so descritos, publicados, localizados e invocados atravs de uma rede de

forma transparente. Neste ponto surge uma interface para que uma aplicao
possa usar a Internet, e no um usurio. Onde aplicativo qualquer possa fazer
a mesma coisa, isso consiste a idia do Web Services (CZERVENY, 2004, p.
51).
A arquitetura e o fluxo que as informaes iro percorrer podero ser
observados na Figura 01.

Figura 01 - Fluxo dos dados na arquitetura Web Service

Fonte: Potts (2003, p. 5).

Um Web Service pode ser considerado como um servio disponvel

na WEB, porm sem telas grficas, que utilizam chamadas e retornos em
formato XML, no caso utilizando padro SOAP.

29

O cliente que utiliza este padro de distribuio precisa de um

arquivo conhecido como Web Service Description Language (WSDL), onde
contm as regras para a comunicao. Logo aps a obteno das informaes
do arquivo, o programador do lado cliente poder montar as classes referentes
ao servio que pretende acessar, e assim criar o seu sistema que acessar e
receber tais informaes (PAULON, 2006).
O Desenvolvimento das aplicaes divido ento em dois: o
servidor e o cliente.
No servidor, onde sero implementados e disponibilizados os
servios, ou seja, todas as regras de funcionalidades dos objetos sero
desenvolvidas, e aqui que o documento WSDL ser armazenado, pois
contm as bases para se estabelecer conexo.
No lado cliente, onde o usurio estar em contato com os recursos
disponibilizados pelos objetos que esto no servidor, pode ser escrito em
qualquer linguagem de programao. Mas dever seguir as especificaes do
documento WSDL.
Existem dois tipos de troca de informao entre o cliente e o servidor
e se diferencia pelo lado que iniciou a comunicao:
a) requisio/resposta: o cliente inicia a ao fazendo uma
requisio ao servidor;
b) solicitao/resposta: o servidor realiza a primeira ao
solicitando uma resposta do cliente.
Simplificando, Web Service a maneira dos aplicativos se
comunicarem e trabalhar juntos via um dispositivo de comunicao ou rede

30

como Intranet e principalmente a Internet. As entidades que interagem so as

seguintes:
a) Solicitadores: geralmente o lado cliente. Uma aplicao que
deseja receber servios de uma outra aplicao. O Cliente
no sabe de onde est vindo s mensagens, nem como
localiz-la, para isso eles recorrem aos agenciadores que
requisita uma operao de busca;
b) Provedores: lado servidor que ir disponibilizar os servios,
possibilitando aos clientes, independentemente de onde se
encontram, acess-los e usufruir alguns dos seus benefcios;
c) Agenciadores:

pea

de

fundamental

importncia

ir

estabelecer o sincronismo de acesso dos dados entre os

lados. O servidor retorna as informaes sobre os servios
em resposta a um critrio de pesquisa que tenha sido
submetido por um solicitador. Essas informaes com base
em classificaes que correspondiam ao critrio de pesquisa
retornam para o Web Services.
Em um momento de comunicao, um provedor de servios ir
publicar a disponibilidade a que se propem e responder a requisies do que
a mesma tenha publicado. A operao de publicao permitir ao provedor
registrar suas habilidades e seus requisitos de interface junto a um agenciador
de servios. E este por sua vez, registrar e ir categorizar os provedores e ir
oferecer esses servios de pesquisa. A operao de busca permitir que o
solicitador encontre a tarefa desejada junto ao agenciador.

31

O solicitador usar o agenciador que, encontrar o servio que

precisa e conecta-se ao provedor para utiliz-lo. A operao de acoplamento
permitir ao solicitador usar o servio encontrado (ZAVALIK, 2006).
A Figura 02 ilustra o procedimento descrito acima:

Figura 02 - Arquitetura bsica de Web Services.

Fonte: ZAVALIK (2006)

A integrao dos Web Services se d sob vrios protocolos abertos,

em diferentes nveis de abstrao. Os protocolos utilizados para realizar esta
comunicao entre diferentes agentes esto dispostos em cinco camadas,
conforme apresentado na Figura 03.

32

Figura 03 - Protocolos de comunicao de Web Services

Fonte: ZAVALIK (2006)

2.3.3 Justificando os Web Services

Fundamento na promessa de interoperabilidade2, com arquitetura

baseada no envio de mensagens XML em um formato SOAP. Estas podem ser
transmitidas facilmente de um computador para outro, pois podem ser
representadas como caracteres ASCII3 comuns.
No importa que tipo de computador, sistema operacional, e nem de
qual lugar do mundo a mensagem SOAP enviada. Nem mesmo em que
linguagem foi escrito o software, e tambm no h necessidade de saber que
tipo de processador SOAP est rodando no servidor.
Toda aplicao de software no mundo potencialmente
capaz de se comunicar com qualquer outra aplicao de software no
mundo. Essa comunicao pode ocorrer por meio de todas as antigas
barreiras de local, sistema operacional, linguagem, protocolo etc
(POTTS, 2003, p. 5).

2
3

Capacidade de se comunicar com tipos diferentes de plataformas de sistemas operacionais

American Standard Code for Information Interchange

33

Os programadores devem se preocupar com o tipo de protocolo de

transporte que ser usado, pois alguns destes so bloqueados pelo firewall4. J
no caso do HTTP este acontecimento quase inexistente.
Como so baseados no protocolo SOAP, qualquer plataforma que
interprete rotinas HyperText Transfer Protocol (HTTP) e manipule XML pode
utilizar os dados dos Web Services sem qualquer problema.
No caso dos Web Services, as conexes so abertas a cada
requisio e fechadas aps o recebimento desta solicitao. A partir do
momento que os dois lados pararem de trocar informaes conexo
automaticamente fechada. Tendo assim a possibilidade de atender muito
mais clientes. O que no ocorre com as tecnologias CORBA e DCOM, que
utilizam conexes permanentes entre o servidor e o cliente.
Antes de se explorar todo o contedo da gramtica SOAP, veremos
uma breve definio de documentos XML.

2.4 eXtensible Markup Language (XML)

O XML uma Linguagem de Marcao Extensvel projetada como

uma verso simplificada da Standard Gerneralized Markup Language (SGML),
a metalinguagem5 usada para definir a gramtica e a sintaxe do Hipertext
Markup Language (HTML) (W3C, 2006).
Formalizada em 1997 pelo grupo W3C XML (GT) do World Wide
Web Consortium (W3C). Veio para facilitar o uso das linguagens de marcao,

Pode ser definido como uma barreira de proteo, que controla o trfego de dados entre seu computador
e a Internet (ou entre a rede onde seu computador est instalado e a Internet).
5
Metalinguagem uma linguagem usada para criar outras linguagens.

34

tanto na parte que refere se a escrita e leitura, como no compartilhamento e

intercambio dos conjuntos de dados (ANDERSON, 2001, p. 11).
De acordo com a W3C(2006), a linguagem XML alm de fornecer os
benefcios da SGML, ela tambm gerencia o contedo e a estrutura do
documento independente do seu tamanho e prove suporte a um nmero
ilimitado de aplicaes.
Com o XML, o layout separado do contedo: portanto, quando
um projetista que modificar o layout de um site, ele simplesmente modifica a
folha de estilo que est anexada. O contedo permanece intacto. (NATANYA,
2000, p.17).
uma linguagem de marcao de muitas tags, instruindo o leitor o
que significa cada informao. Permite definir novas tags, aproveitando a
facilidade e a flexibilidade oferecida com as novas definies de aninhamentos,
podem representar os dados em formas de fontes de dados semi-estruturados
(NATANYA, 2000, p.8).
O quadro 02 mostra os componentes de um documento XML.
Componente

Descrio

Documento XML

um documento contendo dados que obedece a regra da XML

parser XML

programa que reconhece as tags como sua entrada e elabora

uma representao de estruturas de dados com formas legveis

DTD ou Esquema XML

descrio das tags que podem ser utilizadas no documento XML

NamesSpaces

definio que se utiliza para evitar conflitos

Quadro 02 - Componentes do XML

Fonte: Adaptado de Potts (2003, p. 79).

No Quadro 03 podemos observar um exemplo simples de um

documento XML.

35

1
2
3
4
5
6
7

<?xml version="1.0" ?>

- - <!Exemplo de um memorando interno informatizado-->
- - <memorando>
<setor_origem>Compras</setor_origem>
<setor_destino>Informtica</setor_destino>
<contedo>Reinstalar sistema de pedido</contedo>
</memorando>

Quadro 03 - Exemplo de um documento XML

Fonte: Autor.

Na primeira linha est identificada verso do XML, a segunda linha

mostra um comentrio simples, a tag <memorando> o elemento raiz do
documento e os outros elementos so <setor_origem>, <setor_destino> e
<contedo>. Compras, Informtica e Reinstalar sistema de pedido so os
dados do documento XML.
XML no uma extenso para o HTML, eles foram projetados com
objetivos diferentes. O HTML foi projetado para apresentar e formatar os
dados, enquanto o XML foi projetado para descrever e transport-los (W3C
2006).

2.5 Document Type Definitions (DTD)

Segundo Deitel et al (2003, p. 176), as DTDs (Definies de tipos de

documentos) determinam a estrutura de um documento XML, ou seja, o que
deve conter no documento, como: elementos, subelementos, atributos,
seqncia, obrigatoriedade, entre outros.

36

As regras contidas nas DTDs ajudam a validar os dados quando a

aplicao que os recebe no possui internamente uma descrio do dado que
est recebendo.
Os dados enviados com DTD so conhecidos como dados bem
formatados. Nesse caso, o documento pode ser usado para, implicitamente, se
autodescrever.
Uma DTD um conjunto de regras que define as
instrues que sero enviadas ao analisador sinttico para o
documento que est para ser analisado. Uma DTD pode incluir um
conjunto de declaraes de elementos e de atributos e as entidades,
notaes e comentrios que voc quer usar (NATANYA, 2000,
p.99).

Os documentos que usam DTD so chamados de vlidos, pois alm

de seguirem as regras de sintaxe de XML, obedece tambm o vocabulrio
criado pelo autor do documento. Mas a linguagem XML permite documentos
que no utilizam DTD, e que estes sejam bem formatados em sua
estruturao, mas no validados e tais documentos podem ser tidos como
independentes.
As DTDs podem ser inseridas em documentos XML com a
declarao de tipo de documento por meio da tag DOCTYPE. Esta tag pode
apresenta a DTD contida no prprio documento (subconjunto interno), ou
simplesmente apontar para declaraes externas ao documento (subconjunto
externo). De acordo com seu local de armazenamento a DTD pode ser
classificada como pblica (externa) ou de sistema (interna).
A

diferenciao

apresenta-se

exatamente

no

momento

da

declarao do tipo de documento ao especificarmos uma DTD, ou seja, para

usarmos uma DTD pblica deve-se fazer uso da expresso PUBLIC seguida do

37

nome do proprietrio da DTD, exemplos no quadro 04 (NATANYA, 2000, p.

103):

DTD Publica
<!DOCTYPE livro PUBLIC -//EmpresaXYZ//DTD livro//EN
http://www.site.com/dtds/livro.dtd>
DTD local
<!DOCTYPE livro SYSTEM http://www.site.com/dtds/livro.dtd>

Quadro 04 - Exemplo de declarao de DTD

Fonte: Adaptado de Natanya (2000, p. 103).

Sendo assim, uma DTD pode conter:

a) dados

de

caracteres,

inclusive

caracteres

normais

caracteres especiais;
b) caracteres de espao em branco;
c) entidades;
d) elementos, inclusive suas marcas de incio e fim;
e) atributos;
f) comentrios;
g) instrues de processamentos.

Os elementos usam a declarao de tipo (ELEMENT) e representam

blocos de construo fundamentais usados em documentos XML. A sintaxe da
definio do elemento segue a marcao <!ELEMENT nome (especificao)>.
O conjunto de parnteses que segue o nome do elemento especifica o
contedo permitido e chamado de especificao de contedo.
A especificao PCDATA explicita que o elemento deve conter
dados sintaticamente analisveis, exceto os caracteres: <, >, &, e . Outras

38

especificaes de tipos de contedo permitidas so o EMPTY (declara

elementos vazios), ANY (podem possuir qualquer contedo) e o contedo
misto (qualquer combinao de elementos e PCDATA).
Alguns caracteres especiais permitem que o autor defina a ordem e
a freqncia de elementos filhos conforme a tabela 01:

Tabela 01 - Caracteres especiais de definio de ordem e a

freqncia dos elementos
Caracter

Nome

Definio

Vrgula ( , )

Seqncia

Especifica a ordem em que os elementos

podem ocorrer.

Barra vertical ( | )

Escolha

Especifica que o documento deve conter um

ou outro elemento

Sinal de mais ( + )

Indicador de
Ocorrncia

O elemento aparece uma ou mais vezes

Asterisco ( * )

Indicador de
Ocorrncia

O elemento opcional, aparece zero ou mais

vezes

Ponto de interrogao Indicador de

(?)
Ocorrncia

O elemento opcional, aparece zero ou uma

vez

Parnteses ( ( ) )

Dois ou mais elementos ocorrem segundo

uma combinao

Grupo de elementos

Fonte: Anderson (2001, p.87)

Os atributos usam a declarao (ATTLIST) e definem uma lista de

atributos para um determinado elemento. A sintaxe da definio de atributos,
segue <!ATTLIST elemento nome_atributo tipo_atributo default>. Para se
definir valores default de atributos utiliza-se s definies #IMPLIED (atributo
facultativo), #REQUIRED (atributo obrigatrio) e #FIXED (atributo constante).
Os tipos de atributos so classificados como string (CDATA), como
tokens (ID, IDREF, ENTITY e NMTOKEN) ou enumerados (lista de valores
possveis e NOTATION).

39

Na tabela 02 so identificadas as possibilidades para os atributos

tipo tokens.
Tabela 02 - Possibilidades para os atributos tipo tokens
Tipos de Atributo

Possibilidades

ID

Definio nica de um elemento

IDREF

Aponta para elementos com um tipo de atributo ID

ENTITY

Indica uma entidade como valor

NMTOKEN Token com nome Letras, dgitos, pontos, sublinhados hfens e doispontos
Fonte: Anderson (2001, p.92)

O quadro 05 apresenta um exemplo de DTD do documento XML

simples mais funcional.

<? xml version= 1.0?>

<!DOCTYPE memorando [
Figura
10 - DTD domemorando
documento XML
<!ELEMENT
(de,note.xml
para, titulo, corpo)>
<!ELEMENT de (#PCDATA)>
<!ELEMENT para (#PCDATA)>
<!ELEMENT titulo (#PCDATA)>
<!ELEMENT corpo (#PCDATA)>
]>
Quadro 05 - Exemplo de uma DTD
Fonte: Autor

Com a definio do que um documento XML, passamos para a

gramtica SOAP.

40

2.6 Simple Object Access Protocol (SOAP)

O SOAP uma especificao que descreve como transferir dados

de um computador para outro. Originalmente, foi especificado para facilitar as
chamadas de mtodos em outro computador e retornar um resultado. Ele
escrito usando tags no estilo da XML, mas segue um conjunto de regras mais
rgido (CZERVENY, 2004, p. 51).
um modelo para usar a tecnologia existente na rede, utiliza o envio
de mensagens tipo texto sem nenhuma complexidade, permitindo que as
aplicaes comuniquem-se diretamente sem que as protees de segurana
feitas por firewalls s bloqueiem. baseado em XML e independente de
linguagem e plataforma, pois suporta vrios mecanismos de transporte, como:
HTTP, sockets, e-mail, arquivos ou outros mtodos.
Possui

alm

do

corpo

da

mensagem,

um

envelope

(encapsulamento) e cabealho onde estaro as informaes com a

identificao de estados e dados sobre segurana com credenciais.
SOAP um protocolo projetado para invocar aplicaes
remotas atravs de RPC (Remote Procedure Calls - Chamadas
Remotas de Procedimento) ou trocas de mensagens, em um
ambiente independente de plataforma e linguagem de programao.
SOAP , portanto, um padro normalmente aceito para utilizar-se
com Web Services (CUNHA, 2006).

Com as especificaes SOAP os programas so escritos em um

nvel de abstrao suficientemente alto, onde qualquer sistema operacional e
linguagem de programao permitem a criao de programas capazes de
interoperar. A sua infra-estrutura pode ser anloga aos vages de um trem,
pois no especifica tipos dados e nem mtodos. Onde os trens carregam
qualquer coisa que se adapte ao tamanho do seu vago, um produto pode ser

41

transmitido de um ponto A para um ponto B, sendo que os dois lados estejam

dentro da mesma especificao (POTTS, 2003, p.105).

Figura 04 - Camadas do SOAP

Fonte: Potts (2003, p. 106)

Se estiver programado para que no protocolo de transporte HTTP,

possa receber documentos desse formato, ento o arquivo passar para
camada superior onde trata as regras de comunicao do protocolo SOAP,
passando por essas regras de validao.
O Web Service acionado, assim devolvendo a resposta do servio
solicitado. O seu processo de comunicao pode ser mais bem compreendido
como um grupo de camadas como na Figura 04.
Agora veremos a gramtica SOAP em detalhes.

42

2.6.1 Gramtica SOAP

Composta de duas partes obrigatrias e uma opcional. Sendo o

envelope e o corpo, obrigatrios, e o cabealho, opcional. As tags XML
associadas

possuem

prefixo

SOAP-ENV,

assim:

SOAP-ENV:Envelope

(envelope), SOAP-ENV:Header(Cabealho) e SOAP-ENV:Body(corpo). Veja na

figura 05 a representao grfica de um envelope SOAP.
SOAP-ENV:Envelope refere-se ao incio da mensagem, seguindo a
sintaxe, conforme demonstrado o Quadro abaixo.

<SOAP-ENV:Envelope xmlns:SOAP-ENV=schemas.xmlsoap.org/soap/envelope>

Quadro 06 - Definio do Envelope SOAP

Fonte: Potts (2003, p.108)

Descrevendo, o xmlns, significa namespace XML, usado para evitar

conflitos entre as tags. SOAP-ENV provm da sintaxe do protocolo SOAP, a
string

schemas.xmlsoap.org/soap/envelope indica

em

que

verso do

protocolo realizar a comunicao. Quando o Web Service l essa string, ento

ele observa se capaz de trocar informaes ou no. Se a resposta for
negativa, retorna uma mensagem de erro ao chamador.
SOAP-ENV:Body, refere-se ao corpo da mensagem, onde ocorre a
chamada remota de um mtodo que est em outro computador, chamado de
payload. O Corpo pode ainda conter um elemento opcional Fault, usado para
carregar mensagens de status e erros retornadas pelos "ns" ao processarem
a mensagem. Veja um exemplo no Quadro 07:

43

<SOAP-ENV:Body>
<ChecarConta>
<NumeroConta xsi:type=xsd:int>1236545</NumeroConta>
</ChecarConta>
</SOAP-ENV:Body>

Quadro 07 - Envelope SOAP:Body

Fonte: Adaptado de Potts (2003, p. 109).

A primeira linha e a ltima, respectivamente so o incio e o final do

corpo, a segunda linha fornece o mtodo que ser invocado remotamente. O
NumeroConta o parmetro que est sendo passado para mtodo, xsi:type
indica que est sendo passado um atributo, e xsd:int indica o tipo do atributo,
que nesse caso um atributo inteiro (POTTS, 2003, p. 108).
SOAP-ENV:Header, refere-se ao cabealho, elemento opcional,
entretanto, se ele estiver presente, dever ser o primeiro. Esse no consta nas
especificaes do protocolo, mas podem ser repassados ao servio. Como
exemplo, a maneira de que um usurio repassa seus dados para efetuar login
(acessar), e assim utilizar o servio. Veja o quadro 08:

<SOAP-ENV:Header>
<myNS:authentication xmlns: myNS= http://www.testeweb.com/senha
SOAP-ENV:mustUnderstand=1 >
<Usurio>administrador</Usurio>
<Senha>teste</Senha>
</myNS:authentication>
</SOAP-ENV:Header>

Quadro 08 - Envelope SOAP:Header

Fonte: Adaptado de Potts (2003, p.110).

44

Figura 05 - Estrutura de um envelope SOAP

Fonte: Cunha (2006).

O protocolo SOAP nos permite passar informaes sobre seus

possveis tipos de dados, conforme apresentado no quadro 09. Caso no seja
especificado nenhum tipo, o default ser o tipo string (caracteres). Os dados
sempre sero transmitidos em formato tipo texto para posteriormente ser
convertido, conforme o tipo especificado.

<Numero xsi:type = xsd:int>65497</Numero>

Quadro 09 - Declarao de Tipo de dados SOAP.
Fonte: Potts (2003, p. 113)

Segundo Paulon (2006), essa arquitetura tira proveito do nico

formato que todas as marcas e modelos de computadores podem compartilhar
facilmente para comunicarem-se uns com os outros, o modo texto. A tarefa de
converso fica a cargo dos programadores do software cliente usado. Todas as
linguagens de programao podem converter precisamente representaes

45

string em variveis tipificadas, contudo, que se saiba em quais tipos de dados

devem ser armazenadas, conforme mostra a Figura 06.

Figura 06 - Converso dos tipos de dados

Fonte: Potts (2003, p. 113)

2.7 Web Service Description Language (WSDL)

Gramtica XML para especificao das propriedades de um servio

web, tais como: onde est localizado ou quais locais e como invocar o seu
servio, tipos, mensagens, portas e os servios oferecidos. Um documento
WSDL define um XML Schema para descrever um Web Service (CZERVENY,
2004, p 52).
Quando o cliente deseja se comunicar enviando mensagens para
um determinado Web Service, ele obtm a descrio do servio, documento

46

WSDL, s assim constri a mensagem e repassa os parmetros necessrios

com seus respectivos tipos de dados de acordo com as definies WSDL.
A mensagem enviada para o servio conforme localizao
especificada. Ento o cliente fica aguardando a resposta que ir ser
processada. O Web Service, entretanto ao receber a mensagem, valida-a e
assim o servio remoto sabe como tratar a mensagem, como process-la e
como montar a resposta ao cliente, pois toda especificao est contida no
documento WSDL.
Ainda nesse documento, devero ser identificados quais parmetros
necessitar fornecer para estabelecer a comunicao, e quais dados sero
disponibilizados como retorno da chamada do servio.
Contudo esse documento composto por alguns elementos, so
eles:
a) types: identifica que tipo de WSDL est sendo declarado;
b) message: comunicaes entre os computadores, em um
nico sentido. Elemento abstrato que descreve mensagens
lgicas, tendo um resumo do que o servio pode oferecer.
c) operation: qual sistema ser usado na disponibilidade desse
servio, requisio/resposta, solicitao/resposta ou sentido
nico;
d) portType: conjuntos das operaes que o Web Service
poder aceitar e fornece informaes de como se conectar
diretamente ao servio;

47

e) binding: serve como vnculo entre os elementos abstratos e

elementos concretos no esquema e fornecem um continer6
para as informaes, como endereos e protocolos;
f) port: indica o endereo IP e a porta real de comunicao;
g) service:

continer

para

todas

as

portas

que

so

representadas para o servio, porm, um valor limitado, pois

as portas dentro de um servio, no podem ser encadeadas.
h) definitions:

elemento

raiz

contm

especificaes

targetNameSpace, ajuda a evitar conflitos com os nomes das

tags.

Na Figura 07, a representao grfica do esquema de usabilidade

do documento WSDL. Pode-se verificar que esse documento permite conhecer
todos os objetos, procedimentos e funes distribudas que estaro disponveis
para quem precisar utilizar.

Espao que ser utilizado para armazenar algumas informaes com um alto nvel de abstrao

48

Figura 07 - Usabilidade do documento WSDL

Fonte: CUNHA (2006).

2.8 Universal Discovery, Description and Integration (UDDI)

um mecanismo padronizado e transparente que descreve mtodos

simples para solicitar e disponibilizar servios aos usurios que o desejarem
utilizar. Aps registrar o servio, os demais mecanismos UDDI recebero suas
informaes no prximo sincronismo, sendo assim todos os Web Services
devidamente registrados publicam e conhecem uns aos outros (POTTS, 2003,
p. 137).
A integrao e descoberta da descrio universal (UDDI) uma
especificao da indstria para publicar e localizar informaes sobre servios
da Web. A especificao UDDI se baseia no protocolo de acesso a objeto

49

simples (SOAP), a linguagem de marcao extensvel (XML) e padres de

protocolo HTTP.
A combinao de WSDL e UDDI o que lhe permite publicar o
servio, sendo assim descoberto pelos usurios. Porm, a publicao ou no
do seu servio totalmente opcional, ou seja, se desejar colocar um servio
disponvel somente para sua corporao ou de uso pessoal, no necessita
publicar esse servio. Geralmente Web Services possui um nmero muito
restrito de usurios, at pela sua operabilidade, muitos servios desse tipo so
destinados a parceiros comerciais e so raros os que atendem o pblico em
geral (CZERVENY, 2004, p.52).
A Arquitetura utilizada para publicao de servios, similar a
configurao de uma coleo duplicada de Web Services, ou seja, todos os
diretrios pblicos duplicam informaes em qualquer um deles. Desta forma
ele garante o acesso aos servios, como podemos observar na Figura 08.
feita uma analogia com um catlogo telefnico, como tal no muito
amigvel:
a) pginas
telefone

brancas:
de

informaes

contato,

bsicas,

informaes

como:

nome,

legveis para leigos

avaliarem o que o servio oferece;

b) pginas

amarelas:

classificaes

usando

sistemas

taxonmicos, sendo que campos de nichos possam usar seus

cdigos

de

classificao

para

obter

preciso

nas

comparaes das entradas e estas devero ser vlidas.

Podendo usar classificaes geogrficas onde existem
proximidades de endereos;

50

c) pginas verdes: possui os detalhes de como programar o

cliente que solicita o servio, sendo que o mesmo um
dicionrio de dados para descrever os servios.

Figura 08 - Esquema UDDI

Fonte: Potts (2003, p. 138)

2.9 ERP

Franco Jr. (2001, p. 204), conceitua ERP como sendo a evoluo do

MRP II (Material Requeriment Planning) e ao modelo industrial japons, just-intime.
Ou seja, o MRP no incio dos anos 60, prestigia o planejamento e
controle da produo. Evoluiu nos anos 80 para o MRP II, agora utilizando
modelo de pesquisa operacional, incorporando funes de objetivos, perdas,
otimizao de custo e maximizao dos resultados da produo. Ento nos
anos 90, chegamos ao ERP, agora uma integrao completa, RH, Finanas,
Contabilidade, praticamente todos os setores das empresas.

51

O papel do ERP na empresa organizar, codificar e criar padres

para processos internos. Tornou-se a espinha dorsal para integrao dos
setores da empresa.
Agora Franco Jr (2001, p. 212) comea a utilizar um novo termo eERP. A transformao do ERP em e-ERP no muda os conceitos do ERP, mas
implementa a conectividade com os clientes e fornecedores, por meio de EDI
(Electronic Data Interchange) ou IP.
Desta forma, Franco Jr (2001, p. 216) apresenta o trs modelos de
relacionamento externo de e-ERPs.
O modelo da Figura 09 representa uma empresa que permite que os
fornecedores e clientes tenham acesso a seus sistemas internos, mas sem
integrao, somente via web para facilitar o controle e acesso as informaes.

e-Compras

ERP

e-Vendas

Figura 09 - ERP acessado por Clientes e Fornecedores

Fonte: Franco Jr (2001 p. 216)

O modelo da Figura 10 representa vrias empresas com estrutura

semelhante Figura 09, s que com integrao por meio de portais em
determinados segmentos de mercados. Ex. portais de leiles, financiamentos,
entre outros.

52

e-Compras

ERP

e-Vendas
Portal
Externo

e-Compras
e-Compras ERP ERP e-Vendas
e-Vendas
Portal
Figura 10 - Portais integrando diferentes ERPs.
Fonte: Franco Jr (2001, p. 216).

O modelo da Figura 11 representa vrias empresas com estrutura

semelhante Figura 09, com integrao direta, mas agora por portais prprios
ou at mesmo integrao direta de seus ERPs com o uso de Web services.

ERP

e-Compras
e-Vendas
WEB
Services

ERP

Figura 11 - Modelos de ERPs integrados diretamente

Fonte: Franco Jr (2001, p. 216).

A integrao de diferentes empresas requer maior padronizao de

protocolos, pois para obter reduo de custo e aumento da competitividade de
toda cadeia de suprimentos, o meio de comunicao ser a Internet.
A tecnologia da informao desempenha papel importante na
reengenharia da maioria dos processos de negcios. A velocidade, a
capacidade de processamento das informaes e a conectividade das redes de
computadores podem aumentar substancialmente a eficincia dos processos

53

de negcios, bem como as comunicaes e a colaborao entre as pessoas

responsveis por sua cooperao e administrao. (OBRIEN, 2004, p. 54)
Recursos de um Sistema de Informao: Um SI consiste em 5
recursos principais: pessoas, hardware, software, dados e redes, (OBRIEN
2004, p. 12).
a) Recursos humanos: abrange desde os usurios finais aos
especialistas de TI.
b) Recursos de hardware: so todos os dispositivos e
equipamentos utilizados no processamento da informao,
no somente os computadores, mas tambm todas as mdias
envolvidas, desde papel at os discos e fitas magnticas.
c) Recursos de software: refere-se a todos os conjuntos de
instrues de processamento da informao, incluindo os
Sistemas

operacionais,

aplicativos

tambm

os

procedimentos de operao.
d) Recursos de Dados: so os bancos de dados e as bases de
conhecimentos

que

guardam

conhecimento

em

uma

multiplicidade de formas. Os dados so as matrias-primas

para os sistemas de informao.
e) Recursos de Redes: enfatiza que as redes de comunicao
so um componente de recurso fundamental para um Sistema
de Informao.
O envolvimento dos gerentes (alta administrao) e dos usurios
finais (nvel operacional) com a equipe de TI constitui o ingrediente

54

fundamental para se obter sucesso em projetos de desenvolvimento e

implantao de sistemas da informao. (OBRIEN, 2004, p. 404).

2.9.1 Tecnologias aplicadas no Microsiga Protheus.

O ERP da Microsiga denominado Protheus, foi desenvolvido

utilizando a tecnologia cliente/servidor com trs camadas: Cliente e Banco de
dados e Servidor (Regra de Negcios).
Seu projeto busca os conceitos de interoperabilidade e portabilidade,
permitindo que o cliente decida pelo banco de dados e o sistema operacional
que deseja utilizar. Utiliza desde bancos de dados gratuitos como o MySql a
um Oracle ou DB2, alm de permitir que estes utilizem diferentes sistemas
operacionais, como Linux, Windows, HPUX, dentre outros. Esta flexibilidade
tambm valida para os aplicativos servidor e cliente. Sendo que o aplicativo
servidor rodar em Windows e Linux, e o aplicativo cliente roda em Windows,
Linux e como um activex, diretamente no browser, via LAN ou mesmo pela
Internet.
Internamente a Microsiga j incluiu em seu aplicativo servidor,
utilizando o protocolo TCP/IP um servidor de FTP e um servidor de HTTP.
Alm de atender e integrar todos os processos da empresa, como:
produo, contbeis, financeiros e administrativos. Possui diversas outras
tecnologias disponveis, como: Workflow, BSC (Balanced Score-Card), DW
(Data Warehouse), Portais Web, linguagem de programao prpria e Web
Services.

55

Outros aplicativos que compe a soluo: Mdulo configurador,

TopConnect, APSDU, Monitor e um IDE. Estas so ferramentas disponveis
para o gerenciamento e administrao do ambiente como um todo. E por meio
destas ferramentas so efetuada manuteno no banco de dados e regras de
negcios, importante para a aderncia do produto a empresa e vice-versa.
O Configurador o aplicativo que disponibiliza o dicionrio de dados
ativo (tabelas, campos e gatilhos), manuteno de usurios e permisses de
acessos, cadastro de parmetros e tabelas genricas do sistema, bem como
configurao e gerenciamento do workflow, e agendamento de processos para
o sistema.
O TopConnect o gateway que disponibiliza a comunicao do
aplicativo servidor com os bancos de dados homologados.
O APSDU disponibiliza a base de dados por meio da aplicao
cliente, onde consultas e manipulao da base de dados podem ser realizadas
de forma remota, e at mesmo executar consultas SQL adhoc7.
O Monitor o aplicativo responsvel pelo monitoramento do
aplicativo servidor. Permite o gerenciamento dos acessos dos usurios,
identificando o tempo de conexo e em que empresa, filial, mdulo e at qual
rotina o usurio est processando.
Linguagem de programao prpria, denominada ADVPL.
baseada no padro xBase, alm de orientada a objetos, possui recurso para
implementao do workflow, bibliotecas para desenvolvimento de web services
e compilao para handhelds, tanto para palmtop como pocketPC.

Consultas SQL executadas por um usurio diretamente ao banco de dados.

56

O IDE a ferramenta para acesso ao repositrio de programas e

regras de negcios da empresa. Permite efetuar atualizaes do sistema, bem
como customizar rotinas com o uso da linguagem ADVPL e possui recurso de
execuo em modo Debug.
A customizao de novos processos, ou mesmo modificaes nos
processos padres do sistema, ocorrem por meio dos conceitos de funes de
usurios, gatilhos e ponto de entrada. As funes de usurios so para novos
relatrios, cadastros e processos. Os Gatilhos podem ser comparados a
eventos executados aps a alimentao de um determinado campo em um
objeto de edio de dados, mesmo que em cadastros e rotinas com cdigo
fonte no disponibilizado aos clientes. Os pontos de entradas so como uma
extenso do cdigo fonte de uma rotina, permitindo interferir nos processos
padres, alm de permitir a manipulao dos dados durante o processo,
alterando assim as funcionalidades das rotinas padres do sistema.
pelo aplicativo IDE que se desenvolvem os mtodos para os
servios e clientes do web service.

2.10 e-Business

Albertin (2002, p. 58), registra que muitas empresas j esto

utilizando a Web para comunicar-se com clientes e fornecedores pela
publicao de contedo em seus servidores WEB. Motivadas pelo potencial do
comrcio negcio-a-negcio (B2B), assim como pelo negcio-a-consumidor
(B2C).

57

Algumas das barreiras identificadas para adoo da comercializao

pela WEB: facilidade de acesso (alta velocidade); facilidade de uso
(privacidade e segurana) e falta de instrumentos de mensurao da rede (falta
de informao sobre o nmero de pessoas na rede);
Potts (2003, p. 17) cita exemplos como Web Services podem auxiliar
nas relaes entre empresas, sejam elas com fornecedores sejam com seus
clientes. A capacidade de disponibilizar dados de seus sistemas internos
diretamente para os sistemas dos parceiros ou clientes, possibilita um
estreitamento maior nas negociaes com seus fornecedores.
Outra forma de disponibilizar os dados aos parceiros ou clientes, se
no for diretamente de sistema a sistema (Web Service), pode ser por
informaes extradas de sua base de dados disponibilizadas por meio de sua
extranet, com criao de pginas dinmicas.

2.11 EDI

EDI (Eletronic Data Interchange), ou seja, Intercambio eletrnico de

dados. Esta tecnologia j vem sendo utilizada h muitos anos e pr-data o uso
comercial da Internet. Por motivos de largura de banda, as empresas
realizavam a troca de arquivos em formatos previamente definidos e muito
compactos em suas instrues. Sendo assim, os arquivos eram de difcil leitura
e praticamente ilegveis ao ser humano, somente de posse do layout e mesmo
assim com muito esforo para compreender seu contedo. No incio dos anos
80 a instituio American National Standards Institute (ANSI) estabeleceu o
padro denominado X12, para o EDI. Hoje mantido pela Data Interchange

58

Standards Association (DISA). Outro padro ou modelo para EDI, o

UM/EDIFACT (United Nations Eletronic Data Interchange for Administration,
Commerce and Transport) (ANDERSON, 2001, p. 658).
Existem inmeros padres de fato para troca de mensagens
eletrnicas. Mas as empresa parceiras que desejem realizar este tipo de troca
de mensagens, podem criar seus prprios padres sem considerar os modelos
atualmente existentes e ainda assim obter xito em seus negcios.
A exploso do uso comercial da Internet nos anos 90, no
entanto, criou a demanda para modelos mais modernos e mais
facilmente implementados de eBussiness. Por conseguinte, quase
todos os modelos EDI atuais esto sendo revisados para usar XML
como a nova base de suas transaes e mensagens necessrias
(ANDERSON, 2001, p. 659).

Com base nestes aspectos que o trabalho ser desenvolvido,

buscando meios de especificar um modelo para a integrao dos parceiros de
logstica da empresa Anjo Tintas e Solventes.

59

3 INTEGRAO DE FORNECEDORES UTILIZANDO WEB SERVICES

Foi realizado levantamento bibliogrfico sobre as tecnologias que

envolvem o tema e uma pesquisa, cuja tabulao encontrada no apndice K.
Esta foi realizada com empresas usurias do ERP Microsiga Protheus.
O questionrio foi enviado por e-mail (ver modelo no apndice J) aos
profissionais de TI. Com esta pesquisa buscou-se conhecer se estas empresas
utilizam ou planejam utilizar a Internet para integrao com clientes /
fornecedores. Tambm, buscou-se identificar os benefcios e obstculos que as
empresas participantes encontraram durante a implantao do ERP.
Resultados obtidos pela anlise da tabulao da pesquisa:
a) Observa-se que a empresa Microsiga teve uma atuao
regular de implantaes na regio nos ltimos 8 anos;
b) Observa-se que 82% das empresas implantaram sistemas
ERP

buscando

automatizar

otimizar

os

processos

administrativos e contbeis;
c) O maior fator motivador das empresas implantarem sistemas
ERP o aumento da disponibilidade de informaes a alta
administrao, visando agilidade nas decises;
d) O E-mail(33%) e o Workflow(21%) foram as tecnologias
(ferramentas) mais utilizadas para auxiliar os negcios da
empresa, mas importante registrar que as planilhas
continuam sendo ferramentas muito utilizadas sendo que 33%

60

dos clientes a utilizam, mas representa somente 13% do total

das tecnologias;
e) O banco de dados SQL Server com 78% disparado o mais
utilizado;
f) A integrao dos setores da empresa foi resposta unnime
entre os que responderam pesquisa, quando perguntado
sobre os benefcios do ERP;
g) A pesquisa revelou que 67% dos clientes possuem algum tipo
de integrao com parceiros comerciais, sendo que somente
33% usam EDI e destes 80% est ligado aos setores
Comercial e Financeiro sendo que a forma de integrao no
segue um padro;
h) Quanto utilizao de Web Services, um percentual de 50%
registrou a adoo desta tecnologia, sendo que 50% so
utilizados para consulta de dados, 33% para integrao de
base

interna

17%

para

integrao

de

base

de

cliente/fornecedor;
i) Outro fator relevante que 44% registraram o uso das
tecnologias da Internet para realizao de negcios (eBusiness);

3.1. Descrio dos problemas

O processo para gerenciamento e lanamento dos conhecimentos

de frete de venda, tornou-se um gargalo para o setor escrita fiscal da empresa.

61

Pois alm de gerar um volume altssimo de lanamentos, possibilita um grande

nmero de erros, ocasionando pagamentos de impostos errados e re-trabalho
tanto no setor da escrita fiscal como no financeiro. Outro ponto que necessita
de melhoria a conferncia dos valores dos fretes cobrados pelos
fornecedores. Pois devido complexidade e diversidade de regies de entrega
e a no padronizao das cidades, torna a administrao das tabelas de
preos de fretes algo muito difcil de administrar.

3.2. Definio do escopo do projeto

No momento do faturamento de uma nota fiscal, deve-se calcular o

valor do frete, pois neste momento j se tm todos os dados necessrios:
transportador, peso, valor, cidade de entrega ou redespacho e tabela de fretes.
Esta informao dever ser disponibilizada para as reas de logstica, custos e
comercial, alm de ser disponibilizada ao fornecedor via Internet.
O Fornecedor receber um comunicado (e-mail) de que uma coleta
est disponvel, com data e hora para o carregamento.
Os dados das notas fiscais faturadas e carregadas, devem ficar
disponveis para gerao do arquivo de integrao com o sistema do
fornecedor.
O arquivo contendo os conhecimentos e a fatura deve ser gerada
pelo sistema do fornecedor, seguindo as definies de layout disponvel. Mas
ser analisado e posteriormente integrado ao sistema da empresa, diretamente
pelo fornecedor no portal corporativo.

62

Tambm devem ser disponibilizadas por meio do portal corporativo,

informaes sobre os carregamentos para consulta aos fornecedores. Assim os
fornecedores que no possuem sistemas para gerar as informaes
necessrias integrao, possam alimentar os dados dos conhecimentos
diretamente no portal. Desta forma, todos os fornecedores de servios de
transporte podero atender nossas exigncias, quanto gerao de dados dos
conhecimentos de frete.

3.3 Detalhamento do banco de dados e dos processos

O Gerenciador de banco de dados utilizado o ORACLE 9.2. Este j

possui as tabelas definidas e mantidas pelo ERP Microsiga Protheus, mas
algumas modificaes foram necessrias para o desenvolvimento do projeto.
Os

processos

tambm

foram

revistos

para

adequao

das

novas

funcionalidades que esto sendo implementadas.

Para definio da tabela de frete, as tabelas REGIO e TIPO DE
VECULO foram criadas. J as tabelas de CIDADE, FORNECEDOR,
TRANSPORTADORA, NOTA FISCAL DE SAIDA e CARGAS sofreram incluso
de colunas para os relacionamentos e campos de controles.
A figura 12 mostra o relacionamento das tabelas utilizadas.
Foi definido que uma cidade faz parte de uma nica regio, e isso
vlido para todas as transportadoras que prestam servios para a empresa e
suas filiais. Isso facilitar a comparao de preos dos servios prestados alm
da manuteno ficar mais clara e objetiva.

63

Tipo de Veculo

Cidades

Transportadoras

Tabela de Preos
de Frete

Regio

Fornecedores

Pedido de venda

Clientes

Cargas

Conhecimento de
Frete

Nota Fiscal de
Sada

Contas a Receber

Nota Fiscal de
Entrada

Livros Fiscais

Faturas a Receber

Legenda
Contas a Pagar

Tabelas existentes
Tabelas Novas

Faturas a Pagar

Tabelas Alteradas

Figura 12 - Relacionamento do banco de dados

Fonte: Autor (base de dados da Anjo Tintas e Solventes)

Alguns processos foram criados e outros alterados, como o caso do

lanamento de pedidos. Este quando um pedido estiver sendo alimentado, e o

64

tipo do frete for informado CIF, o sistema dispara uma rotina para definio da
transportadora a ser utilizada. Todo pedido com fretes do tipo CIF passaro a
ter uma transportadora credenciada previamente pela empresa, no permitindo
ao vendedor a sua escolher, mas sim, seguindo as regras de prioridade de
regies conforme o cadastrado efetuado. Isso garantir a integridade das
informaes bem como a seleo da melhor transportadora pra entrega na
regio. Somente ser permitida a troca de transportadora pela expedio, onde
este processo tambm sofreu alterao.
Todo carregamento realizado na empresa necessita de uma
montagem de carga, e neste processo foi permitida a substituio de
transportadora, bem como a definio do tipo de fretamento (Fracionado /
Fechado), alm da dada e hora da coleta. Isso ir incidir diretamente no valor
do frete calculado para as notas fiscais desta carga. Aps uma carga montada,
um e-mail ser encaminhado automaticamente ao transportador para informar
da coleta e disponibiliza os dados no portal.
Outro procedimento foi totalmente automatizado, o de conferncia
e lanamento dos conhecimentos de frete. Pois este ser todo realizado pelo
fornecedor do servio de transporte, por meio do portal, utilizando o EDI ou
alimentando manualmente se necessrio. A automatizao tambm beneficia o
setor financeiro, no que se trata da montagem das faturas dos conhecimentos
de frete. Este processo pelo alto volume de conhecimentos ocupa um
percentual considervel de tempo da pessoa responsvel pelo setor contas a
pagar, agora passa a ser realizado pelo sistema.
Pode-se destacar tambm a qualidade da informao disponvel ao
BI da empresa, permitindo acesso a informao antecipada do valor do frete a

65

ser pago. Alm de permitir incluir este valor em anlises separadas por
vendedor e regio, pois este valor estar disponvel e rateado por produto em
cada nota fiscal faturada.

3.3. Definio do layout dos arquivos

Por definio, o EDI utilizar dois formatos de arquivos diferentes,

XML e TXT. Assim todos os fornecedores podero aderir ao projeto com
facilidade.

3.3.1 Arquivo de envio das notas para os fornecedores

Analisamos as informaes necessrias para a gerao dos

conhecimentos junto com alguns fornecedores e as definimos conforme quadro
abaixo. O layout proposto atender todas as necessidades dos fornecedores
de servios. Para atender as definies dos arquivos, abaixo apresentamos os
arquivos em formato TXT e XML.

3.3.1.1 Layout no formato TXT

Ord Descrio
Registro 1 - Cabealho
1 Identificao do registro - 01
2 Data Gerao
3 Hora Gerao
4 CNPJ Estabelecimento
5 Inscr.Estadual Estabelec.
6 Nome Estabelecimento
7 Contador Seq. de Envio
8 Seq. da Linha do Arquivo
Registro 2 - Destinatrio

Tam. Incio Fim Contedo Observao

2
8
6
14
14
35
6
6

1
3
11
17
31
45
80
86

2
10
16
30
44
79
85
91

Caracter
Caracter
Caracter
Caracter
Caracter
Caracter
Numrico
Numrico

Fixo "01"
ddmmaaaa
hhmmss
99999999999999
99999999999999
999999
999999

66

1 Identificao do registro - 02
2
2 CNPJ Destinatrio
14
3 Inscr.Estadual Destinatrio
14
4 Nome Destinatrio
35
5 Endereo Destinatrio
40
6 Bairro Destinatrio
20
7 Cidade Destinatrio
35
8 UF Destinatrio
2
9 CEP Destinatrio
8
10 Seq.da Linha do Arquivo
6
Registro 3 - Nota Fiscal
1 Identificao do registro - 03
2
2 Srie NF
3
3 Nmero NF
6
4 Data Emisso
8
5 Tipo do Frete
1
6 Quantidade Volumes
6
7 Peso Bruto
11
8 Valor Nota Fiscal
11
9 Cubagem
11
10 Produto
25
11 Embalagem
10
12 UF Origem
2
13 Cidade Origem
35
14 UF Destino
2
15 Cidade Destino
35
16 Seq. da Linha do Arquivo
6
Registro 4 - Endereo de Entrega (Opcional)
1 Identificao do registro - 04
2
2 Endereo de Entrega
40
3 Bairro Entrega
20
4 Cidade Entrega
35
5 UF Entrega
2
6 CEP Entrega
8
7 Seq. da Linha do Arquivo
6
Registro 5 Redespacho (Opcional)
1 Identificao do registro - 05
2
2 Indicao de Redespacho
64
3 Nome Transp. Redespacho
30
4 Endereo Redespacho
40
5 Bairro Redespacho
20
6 Cidade Redespacho
35
7 UF Redespacho
2
8 CEP Redespacho
8
9 Seq. da Linha do Arquivo
6
Registro 6 - Rodap
1 Identificao do registro - 06
2
2 Quantidade de Registros
6
3 Seq. da Linha do Arquivo
6

1
3
17
31
66
106
126
161
163
171

2
16
30
65
105
125
160
162
170
176

Caracter
Caracter
Caracter
Caracter
Caracter
Caracter
Caracter
Caracter
Caracter
Numrico

1
3
6
12
20
21
27
38
49
60
85
95
97
132
134
169

2
5
11
19
20
26
37
48
59
84
94
96
131
133
168
174

Caracter
Caracter
Caracter
Caracter
Caracter
Numrico
Numrico
Numrico
Numrico
Caracter
Caracter
Caracter
Caracter
Caracter
Caracter
Numrico

Fixo "02"
99999999999999
99999999999999

99999999
999999
Fixo "03"
999999
ddmmaaaa
C=CIF e F=FOB
999999
99999999999 (3 dec)
99999999999 (2dec)
99999999999 (3 dec)
Ex: "Qumico"
Ex: "Tambor"
(Onde inicia o frete)
(Onde termina o frete)
999999

1
2 Caracter Fixo "04"
3 42 Caracter
43 62 Caracter
63 97 Caracter
98 99 Caracter
100 107 Caracter
108 113 Numrico 999999
1
3
67
97
137
157
192
194
202
1
3
9

2
66
96
136
156
191
193
201
207

Caracter Fixo "05"

Caracter
Caracter
Caracter
Caracter
Caracter
Caracter
Caracter
Numrico 999999

2 Caracter Fixo "06"

8 Numrico 999999
14 Numrico 999999

67

Para a criao do arquivo no formato TXT, algumas regras devem

ser observadas.
a) No arquivo somente dever existir um registro tipo 01,
cabealho, e um registro tipo 06, rodap.
b) Os registros tipo 02, destinatrio, dever ter um ou mais
registros tipo 03, nota fiscal, relacionada a ele, ou seja,
abaixo de um registro tipo 02, dever existir pelo menos um
registro do tipo 03.
c) Os registros tipo 04, endereo de entrega, e o tipo 05,
redespacho, so opcionais, mas se existirem se relaciona
com registro tipo 03 imediatamente acima deste.
d) Todas as linhas do arquivo tero como ltima informao o
nmero seqencial da linha.

3.3.1.2 Layout no formato XML

Com a DTD abaixo apresentada, o arquivo XML submetido a ela

estar certificado de seu formato e validao. Este apresenta uma legibilidade
sem igual comparada ao arquivo no formato TXT.
<?xml encoding="UTF-8"?>
<!ELEMENT Arquivo (Cabecalho,Nota+)>
<!ELEMENT Cabecalho (Data, Hora, CNPJ, INSC_ESTADUAL, Nome, Controle_Sequencial)>
<!ELEMENT Nota (Emissao,Tipo_Frete,Volumes,Peso,Valor, (Cubagem, Produto,
Embalagem)?, Origem, Destino, Destinatario, Endereco_Entrega?, Redespacho?)>
<!ATTLIST Nota Numero CDATA #REQUIRED
Serie
CDATA #REQUIRED>
<!ELEMENT Data (#PCDATA)>
<!ELEMENT Hora (#PCDATA)>
<!ELEMENT Controle_Sequencial (#PCDATA)>
<!ELEMENT Emissao (#PCDATA)>
<!ELEMENT Tipo_Frete (#PCDATA)>
<!ELEMENT Volumes (#PCDATA)>
<!ELEMENT Peso (#PCDATA)>
<!ELEMENT Valor (#PCDATA)>

68

<!ELEMENT Cubagem EMPTY>

<!ELEMENT Produto (#PCDATA)>
<!ELEMENT Embalagem (#PCDATA)>
<!ELEMENT Origem (Cidade,Estado)>
<!ELEMENT Destino (Cidade,Estado)>
<!ELEMENT Destinatario (CNPJ, INSC_ESTADUAL, Nome, Endereco)>
<!ELEMENT Endereco_Entrega (Endereco)>
<!ELEMENT Redespacho (Indicacao?, Nome_Transportador_Redespacho, Endereco)>
<!ELEMENT Indicacao (#PCDATA)>
<!ELEMENT Nome_Transportador_Redespacho (#PCDATA)>
<!ELEMENT CNPJ (#PCDATA)>
<!ELEMENT INSC_ESTADUAL (#PCDATA)>
<!ELEMENT Nome (#PCDATA)>
<!ELEMENT Cidade (#PCDATA)>
<!ELEMENT Estado (#PCDATA)>
<!ELEMENT Endereco (Logradouro,Bairro,Cidade,Estado,CEP)>
<!ELEMENT Logradouro (#PCDATA)>
<!ELEMENT Bairro (#PCDATA)>
<!ELEMENT CEP (#PCDATA)>

Agora para demonstrar o tipo de arquivo XML ser validade por esta
DTD, segue abaixo um exemplo:

<?xml version="1.0"?>
<!DOCTYPE Arquivo SYSTEM "file:///e:/Documentos/Monografia_Pos-Graduao/EDI%20%20Logistica/DTD_Externa_Envio.dtd">
<Arquivo>
<Cabecalho>
<Data>25/05/2006</Data>
<Hora>15:24:00</Hora>
<CNPJ>01001002000199</CNPJ>
<INSC_ESTADUAL>12345678910</INSC_ESTADUAL>
<Nome> Anjo Tintas e Solventes </Nome>
<Controle_Sequencial>000001</Controle_Sequencial>
</Cabecalho>
<Nota Serie="1" Numero="000001">
<Emissao>25/05/2006</Emissao>
<Tipo_Frete>CIF</Tipo_Frete>
<Volumes>15</Volumes>
<Peso>15000.000</Peso>
<Valor>24350.25</Valor>
<Cubagem></Cubagem>
<Produto>Quimico</Produto>
<Embalagem>Tambor</Embalagem>
<Origem>
<Cidade>Criciuma</Cidade>
<Estado>SC</Estado>
</Origem>
<Destino>
<Cidade>Sao Paulo</Cidade>
<Estado>SP</Estado>
</Destino>
<Destinatario>
<CNPJ>01111002000155</CNPJ>
<INSC_ESTADUAL>001225445</INSC_ESTADUAL>

69

<Nome>Tinta Sao Paulo</Nome>

<Endereco>
<Logradouro>Av Teste, 200</Logradouro>
<Bairro>Centro</Bairro>
<Cidade>Sao Paulo</Cidade>
<Estado>SP</Estado>
<CEP>88810450</CEP>
</Endereco>
</Destinatario>
<Endereco_Entrega>
<Endereco>
<Logradouro>Av Teste, 200</Logradouro>
<Bairro>Centro</Bairro>
<Cidade>Sao Paulo</Cidade>
<Estado>SP</Estado>
<CEP>88810450</CEP>
</Endereco>
</Endereco_Entrega>
<Redespacho>
<Indicacao>CIF ate o redespacho, FOB ate o cliente</Indicacao>
<Nome_Transportador_Redespacho>
Ouro negro
</Nome_Transportador_Redespacho>
<Endereco>
<Logradouro>Av Teste, 200</Logradouro>
<Bairro>Centro</Bairro>
<Cidade>Sao Paulo</Cidade>
<Estado>SP</Estado>
<CEP>88810450</CEP>
</Endereco>
</Redespacho>

</Nota>
<Nota Serie="1" Numero="000002">
<Emissao>25/05/2006</Emissao>
<Tipo_Frete>CIF</Tipo_Frete>
<Volumes>15</Volumes>
<Peso>15000.000</Peso>
<Valor>24350.25</Valor>
<Cubagem></Cubagem>
<Produto>Quimico</Produto>
<Embalagem>Tambor</Embalagem>
<Origem>
<Cidade>Criciuma</Cidade>
<Estado>SC</Estado>
</Origem>
<Destino>
<Cidade>Sao Paulo</Cidade>
<Estado>SP</Estado>
</Destino>
<Destinatario>
<CNPJ>01111002000155</CNPJ>
<INSC_ESTADUAL>001225445</INSC_ESTADUAL>
<Nome>Tinta Sao Paulo</Nome>
<Endereco>
<Logradouro>Av Teste, 200</Logradouro>
<Bairro>Centro</Bairro>
<Cidade>Sao Paulo</Cidade>
<Estado>SP</Estado>
<CEP>88810450</CEP>
</Endereco>

70

</Destinatario>
<Redespacho>
<Nome_Transportador_Redespacho>
Ouro negro
</Nome_Transportador_Redespacho>
<Endereco>
<Logradouro>Av Teste, 200</Logradouro>
<Bairro>Centro</Bairro>
<Cidade>Sao Paulo</Cidade>
<Estado>SP</Estado>
<CEP>88810450</CEP>
</Endereco>
</Redespacho>

</Nota>
<Nota Serie="1" Numero="000003">
<Emissao>25/05/2006</Emissao>
<Tipo_Frete>CIF</Tipo_Frete>
<Volumes>15</Volumes>
<Peso>15000.000</Peso>
<Valor>24350.25</Valor>
<Origem>
<Cidade>Criciuma</Cidade>
<Estado>SC</Estado>
</Origem>
<Destino>
<Cidade>Sao Paulo</Cidade>
<Estado>SP</Estado>
</Destino>
<Destinatario>
<CNPJ>01111002000155</CNPJ>
<INSC_ESTADUAL>001225445</INSC_ESTADUAL>
<Nome>Tinta Sao Paulo</Nome>
<Endereco>
<Logradouro>Av Teste, 200</Logradouro>
<Bairro>Centro</Bairro>
<Cidade>Sao Paulo</Cidade>
<Estado>SP</Estado>
<CEP>88810450</CEP>
</Endereco>
</Destinatario>
</Nota>
</Arquivo>

3.3.2 Arquivo dos conhecimentos e das faturas emitidas pelo fornecedor

Os dados necessrios para a realizao de todos processos

definidos no escopo, entrada dos conhecimentos, contas a pagar e montagem
das faturas, foram discutido com os responsveis de cada setor em conjunto

71

com a rea de TI, resultando no layout abaixo, tambm em formato TXT e

XML.

3.3.2.1 Layout no formato TXT

.
Ord Descrio
Tam
Incio Fim
Registro 1 - Transportador
1 Identificao do registro - 01
2
1
2
2 CNPJ Transportador
14
3
16
4 Nome Transportador
35
17
51
5 CNPJ Filial Faturamento
14
52
65
6 Data Gerao
8
66
73
7 Hora Gerao
6
74
79
8 Contador Seq. de Envio
6
80
85
9 Seq. da Linha do Arquivo
6
86
91
Registro 2 - Conhecimento
1 Identificao do registro - 02
2
1
2
2 Serie do Conhecimento
3
3
5
3 Numero do Conhecimento
6
6
11
4 Data da Emissao
8
12
19
5 Data de Vencimento
8
20
27
6 Cidade Origem
35
28
62
7 Estado Origem
2
63
64
8 Cidade Destino
35
65
99
9 Estado Destino
2
100 101
10 Valor Total das Mercadorias
11
102 112
11 Peso Total das Mercadorias
11
113 123
12 Alquota do Icms
4
124 127
13 Taxa
11
128 138
14 Pedgio
11
139 149
15 AD Valores (Frete Valor)
11
150 160
16 Valor do Conhecimento
11
161 171
17 Valor do Icms
11
172 182
18 Seq. da Linha do Arquivo
6
183 188
Registro 3 - Notas Fiscais
1 Identificao do registro - 03
2
1
2
2 Serie da Nota Fiscal
3
3
5
3 Numero da Nota Fiscal
6
6
11
4 CNPJ Destinatrio
14
12
25
5 Nome Destinatrio
65
26
90
6 Frete Cortesia (SIM / NO)
1
91
91
7 Data da Emisso
8
92
99
8 Valor da Nota Fiscal
11
100 110
9 Peso da Nota Fiscal
11
111 121
10 Valor do Frete
11
122 132
11 Icms do Frete
11
133 143
12 Seq. da Linha do Arquivo
6
144 149

Contedo

Observao

Caracter
Caracter
Caracter

Fixo "01"
99999999999999

Caracter
Caracter
Numrico
Numrico

Ddmmaaaa
Hhmmss
999999
999999

Caracter
Caracter
Caracter
Caracter
Caracter
Caracter
Caracter
Caracter
Caracter
Numrico
Numrico
Caracter
Caracter
Caracter
Caracter
Caracter
Caracter
Numrico

Fixo "02"
XXX
999999
Ddmmaaaa
Ddmmaaaa

Caracter
AAA
999999
Caracter
Caracter
Caracter
Caracter
Caracter
Numrico
Caracter
Caracter
Numrico

99999999999 2 dec
99999999999 3 dec
9999 2 dec
99999999999 2 dec
99999999999 2 dec
99999999999 2 dec
99999999999 2 dec
99999999999 2 dec
999999
Fixo "03"

99999999999999
S=Sim / N=No
Ddmmaaaa
99999999999 2 dec
99999999999 3 dec
99999999999 2 dec
99999999999 2 dec
999999

72

Registro 4 Fatura (Opcional)

1 Identificao do registro - 04
2 Prefixo
3 Numero da Fatura
4 Parcela
5 Data da Emissao
6 Data de Vencimento
7 Valor da Fatura
8 Seq. da Linha do Arquivo
Registro 5 Fechamento
1 Identificao do registro - 05
2 Num.Total Conhecimentos
3 Valor Total Conhecimentos
4 Num.Total de Notas fiscal
5 Valor da Fatura
6 Seq. da Linha do Arquivo

2
3
6
1
8
8
11
6

1
3
6
12
13
21
29
40

2
5
11
12
20
28
39
45

Caracter
Caracter
Caracter
Caracter
Caracter
Caracter
Caracter
Numrico

Fixo "04"
XXX
999999
[A..Z]
Ddmmaaaa
Ddmmaaaa
99999999999 2 dec
999999

2
6
11
6
11
6

1
3
9
20
26
37

2
8
19
25
36
42

Caracter
Numrico
Caracter
Numrico
Caracter
Numrico

Fixo "05"
999999
99999999999 2 dec
999999
99999999999 2 dec
999999

Para a criao do arquivo de recebimento no formato TXT, algumas

regras devem ser observadas.
a) Em

todo

arquivo

somente

um

registro

tipo

01,

transportador, e um registro tipo 05, fechamento, devero

existir.
b) O registro tipo 02, conhecimento, dever conter um ou mais
registros tipo 03, notas fiscais, relacionado e imediatamente
abaixo dele.
c) O registro tipo 04, fatura, opcional. Mas se existir estar
relacionado diretamente com os conhecimentos acima dele,
compreendidos entre o registro tipo 01 e o prprio registro
tipo 04, ou de um tipo 04 anteriormente declarado at o
prprio registro.

Alm das regras de criao do arquivo, para o layout de

recebimento, foram definidas duas etapas de validao do arquivo. Definidas
como validao primria e validao secundria. Sendo que a validao

73

primria refere-se checagem da sintaxe do arquivo e conferncia de

fechamento de valores diretamente no arquivo para validar sua integridade. J
a validao secundria, refere-se a validao do contedo do arquivo com a
base de dados da empresa, e s ser realizada se a validao primria for
realizada com sucesso.
Para a validao primria, os arquivos devem:
a) obedecer seqncia das linhas;
b) obedecer as regras de criao, quanto ao relacionamento dos
registros;
c) validar os campos Valor Total das Mercadorias e Peso
Total das Mercadorias do registro tipo 02, com o somatrio
dos campos Valor da Nota Fiscal e Peso da Nota Fiscal
dos registros tipo 03 subseqentes at o prximo registro
diferente de 03;
d) validar o campo Valor da Fatura do registro tipo 04, com o
somatrio do campo Valor do Conhecimento dos registros
tipo 02 relacionados8 com ele.
e) validar os campos do registro 05 considerando o arquivo
inteiro, sendo o campo Num.Total Conhecimentos com a
contagem de registros tipo 02; o campo Valor Total
Conhecimentos com o somatrio do campo Valor do
Conhecimento dos registros tipo 02; o campo Num.Total
de Notas fiscal com a contagem de registros tipo 03; o
campo Valor da Fatura com o somatrio do campo Valor da
8

Relacionamento dos registros tipo 02 com os tipo 04, foi explicado no item c das regras de
criao do arquivo de recebimento.

74

Fatura dos registros tipo 04, caso no exista nenhum

registro tipo 04, por ser opcional, este deve ser 0;

Para a validao secundria, os arquivos devem:

a) validar o campo CNPJ Transportador do registro tipo 01, e
verificar se este fornecedor est cadastrado na base de dados
e se possui indicador de integrao via EDI ativa;
b) validar o campo CNPJ Filial de Faturamento do registro tipo
01, refere-se a uma filial valida da empresa;
c) validar o campo Numero da Nota Fiscal do registro tipo 03,
se esta nota fiscal existe na base de dados e se a
transportadora de despacho ou redespacho o fornecedor
validado no item a e verificar se esta nota fiscal j no teve
conhecimento incluso na base de dados;
d) validar os campos Valor da Nota Fiscal e Valor do Frete do
registro tipo 03 com os valores reais das notas fiscais e dos
valores dos fretes armazenados referente a tabela de frete do
fornecedor, caso o item c tenha sido validado corretamente;

3.3.2.2 Layout no formato XML

Esta DTD representa todo esforo para padronizao e efetivao

do projeto de maneira a dar liberdade aos fornecedores no momento de gerar
os arquivos para integrao do EDI.

75

<?xml encoding="UTF-8"?>
<!ELEMENT Retorno (Transportador,Dados,Fechamento)>
<!ELEMENT Transportador (Nome,Data,Hora)>
<!ATTLIST Transportador
CNPJ CDATA #REQUIRED>
<!ELEMENT Dados (Doc_Fatura)+>
<!ATTLIST Dados
Filial_Faturamento CDATA #REQUIRED>
<!ELEMENT Fechamento (Numero_Conhecimentos,Valor_Conhecimentos,
Numero_Notas,Valor_Notas)>
<!ELEMENT Data (#PCDATA)>
<!ELEMENT Hora (#PCDATA)>
<!ELEMENT Doc_Fatura (Conhecimento,Fatura?)>
<!ELEMENT Numero_Conhecimentos (#PCDATA)>
<!ELEMENT Valor_Conhecimentos (#PCDATA)>
<!ELEMENT Numero_Notas (#PCDATA)>
<!ELEMENT Valor_Notas (#PCDATA)>
<!ELEMENT Conhecimento (Emissao,Vencimento,Origem,Destino,
Valor_Mercadorias,Peso_Mercadorias,
Aliquota_ICMS,Taxa,Pedagio,ADValore,
Valor_Conhecimento,Valor_ICMS,Nota+)>
<!ATTLIST Conhecimento
Numero CDATA #REQUIRED
Serie CDATA #REQUIRED>
<!ELEMENT Fatura (Emissao,Vencimento,Valor_Fatura)>
<!ATTLIST Fatura
Numero CDATA #REQUIRED
Parcela CDATA #REQUIRED
Prefixo CDATA #REQUIRED>
<!ELEMENT Origem (Cidade,Estado)>
<!ELEMENT Destino (Cidade,Estado)>
<!ELEMENT Valor_Mercadorias (#PCDATA)>
<!ELEMENT Peso_Mercadorias (#PCDATA)>
<!ELEMENT Aliquota_ICMS (#PCDATA)>
<!ELEMENT Taxa (#PCDATA)>
<!ELEMENT Pedagio (#PCDATA)>
<!ELEMENT ADValore (#PCDATA)>
<!ELEMENT Valor_Conhecimento (#PCDATA)>
<!ELEMENT Valor_ICMS (#PCDATA)>
<!ELEMENT Nota (CNPJ,Nome,Cortesia,Emissao,Valor_Nota,Peso_Nota,
Valor_Frete,ICMS_Frete)>
<!ATTLIST Nota
Numero CDATA #REQUIRED
Serie CDATA #REQUIRED>
<!ELEMENT Valor_Fatura (#PCDATA)>
<!ELEMENT CNPJ (#PCDATA)>
<!ELEMENT Cortesia (#PCDATA)>
<!ELEMENT Valor_Nota (#PCDATA)>
<!ELEMENT Peso_Nota (#PCDATA)>
<!ELEMENT Valor_Frete (#PCDATA)>
<!ELEMENT ICMS_Frete (#PCDATA)>
<!ELEMENT Nome (#PCDATA)>
<!ELEMENT Emissao (#PCDATA)>
<!ELEMENT Vencimento (#PCDATA)>
<!ELEMENT Cidade (#PCDATA)>
<!ELEMENT Estado (#PCDATA)>

76

Exemplo de um arquivo validado por esta DTD. O fornecedor poder

gerar o arquivo XML com a DTD interna ou externa, desde a localizao da
DTD seja a mesma especificada pela empresa.

<?xml version="1.0"?>
<!DOCTYPE Retorno SYSTEM "file:///e:/Documentos/Monografia_Pos-Graduao/EDI%20%20Logistica/DTD_Externa_Recebimento.dtd">
<Retorno>
<Transportador CNPJ="01002003000199">
<Nome>Italia Transportes</Nome>
<Data>24/05/20006</Data>
<Hora>19:20:00</Hora>
</Transportador>
<Dados Filial_Faturamento="10200300000188">
<Doc_Fatura>
<Conhecimento Serie="1" Numero="000001">
<Emissao>24/05/20006</Emissao>
<Vencimento>05/06/20006</Vencimento>
<Origem>
<Cidade>Criciuma</Cidade>
<Estado>SC</Estado>
</Origem>
<Destino>
<Cidade>Sao Paulo</Cidade>
<Estado>SP</Estado>
</Destino>
<Valor_Mercadorias>500000.00</Valor_Mercadorias>
<Peso_Mercadorias>24000.000</Peso_Mercadorias>
<Aliquota_ICMS>12.00</Aliquota_ICMS>
<Taxa>0.00</Taxa>
<Pedagio>0.00</Pedagio>
<ADValore>130.00</ADValore>
<Valor_Conhecimento>1240.00</Valor_Conhecimento>
<Valor_ICMS>150.00</Valor_ICMS>
<Nota Serie="1" Numero="001000">
<CNPJ>01123456000120</CNPJ>
<Nome>Tintas Sao Paulo</Nome>
<Cortesia>S</Cortesia>
<Emissao>24/05/20006</Emissao>
<Valor_Nota>50000.00</Valor_Nota>
<Peso_Nota>24000.000</Peso_Nota>
<Valor_Frete>1240.00</Valor_Frete>
<ICMS_Frete>150.00</ICMS_Frete>
</Nota>
<Nota Serie="1" Numero="001001">
<CNPJ>01001123000122</CNPJ>
<Nome>Com.de Tintas SP</Nome>
<Cortesia>N</Cortesia>
<Emissao>24/05/20006</Emissao>
<Valor_Nota>60000.00</Valor_Nota>
<Peso_Nota>24000.000</Peso_Nota>
<Valor_Frete>1325.00</Valor_Frete>
<ICMS_Frete>150.00</ICMS_Frete>
</Nota>
</Conhecimento>

77

<Fatura Prefixo="FAT" Numero="002222" Parcela="A">

<Emissao>24/05/20006</Emissao>
<Vencimento>05/06/20006</Vencimento>
<Valor_Fatura>2565.00</Valor_Fatura>
</Fatura>
</Doc_Fatura>
<Doc_Fatura>
<Conhecimento Serie="1" Numero="000002">
<Emissao>24/05/20006</Emissao>
<Vencimento>05/06/20006</Vencimento>
<Origem>
<Cidade>Criciuma</Cidade>
<Estado>SC</Estado>
</Origem>
<Destino>
<Cidade>Sao Paulo</Cidade>
<Estado>SP</Estado>
</Destino>
<Valor_Mercadorias>500000.00</Valor_Mercadorias>
<Peso_Mercadorias>24000.000</Peso_Mercadorias>
<Aliquota_ICMS>12.00</Aliquota_ICMS>
<Taxa>0.00</Taxa>
<Pedagio>0.00</Pedagio>
<ADValore>130.00</ADValore>
<Valor_Conhecimento>1240.00</Valor_Conhecimento>
<Valor_ICMS>150.00</Valor_ICMS>
<Nota Serie="1" Numero="002001">
<CNPJ>01001123000122</CNPJ>
<Nome>Com.de Tintas SP</Nome>
<Cortesia>N</Cortesia>
<Emissao>24/05/20006</Emissao>
<Valor_Nota>60000.00</Valor_Nota>
<Peso_Nota>24000.000</Peso_Nota>
<Valor_Frete>1325.00</Valor_Frete>
<ICMS_Frete>150.00</ICMS_Frete>
</Nota>
</Conhecimento>
</Doc_Fatura>
</Dados>
<Fechamento>
<Numero_Conhecimentos>1</Numero_Conhecimentos>
<Valor_Conhecimentos>2565.00</Valor_Conhecimentos>
<Numero_Notas>2</Numero_Notas>
<Valor_Notas>110000.00</Valor_Notas>
</Fechamento>
</Retorno>

78

3.4 Definio dos dados disponveis na Internet para os fornecedores

3.4.1 Estrutura do portal para o fornecedor

Para atender ao escopo do projeto, um website (portal) dever ser

disponibilizado para os fornecedores de transportes, com a finalidade de
acompanhar e gerenciar as informaes referentes s coletas na empresa.
O site tem dois enfoques principais:
a) atender os fornecedores que iro utilizar seus sistemas
internos para receber e gerar os arquivos do EDI. Assim o
portal ir gerar o arquivo das notas fiscais coletadas e
tambm integrar o arquivo dos conhecimentos gerados pelos
fornecedores;
b) atender os fornecedores que no iro utilizar, ou no
possuam, sistemas para a integrao com o EDI. Assim o
portal disponibilizar todas as notas fiscais coletadas e
permitir o fornecedor alimentar manualmente os dados
referentes aos conhecimentos emitidos, e desta forma, por
meio de web services ir fazer a integrao destas
informaes ao ERP.

79

3.4.2 Fluxo do processo com sistemas integrados

Acesso ao Portal

Consulta a coleta
disponibilizada
(Cargas)

Sistema
proprietrio
do fornecedor

Gera arquivo EDI

(Carga)
Formato: TXT ou XML

Gera os conhecimentos

Monta arquivo EDI

(Conhecimentos)
Formato: TXT ou XML

Validao
EDI est OK?

No

Sim
Realiza os processos:
- Entrada dos Conhecimentos
- Lana Contas a Pagar
- Monta Faturas

FIM
Figura 13 - Fluxo do processo com sistemas integrados
Fonte: O autor

80

3.4.3 Fluxo do processo com sistemas no integrados

Acesso ao Portal

Consulta a coleta
disponibilizada
(Cargas)

Alimenta as Notas
com os dados dos
Conhecimentos

Efetiva Integrao

Realiza os processos:
- Entrada dos Conhecimentos
- Lana Contas a Pagar
- Monta Faturas

FIM

Figura 14 - Fluxo para o processo com sistemas no integrado

Fonte: O Autor

81

3.4.1 Definio das opes do portal

O portal do transportador ser anexado ao portal do fornecedor, no

qual possui opes de consulta dos pedidos de compra, posio financeira, e
manuteno de seus dados cadastrais e senha de acesso.
Como o foco o portal do frete (fornecedor de logstica), este ter
habilitado no menu uma opo especial, FRETE, que somente estes tero
acesso.
Detalhando melhor esta opo, temos como subitens do menu frete,
Consulta de Cargas, Validao, Consulta Coletas e Conhecimento de Frete.
A Consulta de cargas realiza uma pesquisa na base de dados,
recebendo como parmetro a data de emisso da carga (incio e fim). Assim
apresenta as cargas j faturadas da transportadora conectada (ver tela de login
no apndice A), sendo que por meio desta rotina podem ser gerados os
arquivos de integrao definido no item 3.3.1. Quando este arquivo gerado, o
mesmo encaminhado via e-mail transportadora. Ainda podem ser filtradas
as cargas pendentes ou no quanto gerao do arquivo. Ver tela em
apndice B.
A opo validao por onde o arquivo de integrao dos
conhecimentos de fretes gerados pelo fornecedor ser integrado ao sistema da
empresa. Aqui o fornecedor ir informar o caminho e nome do arquivo, TXT ou
XML, que contm os conhecimentos e faturas de uma ou vrias cargas
coletadas na empresa (apndice C). Uma bateria de testes ser realizada no
arquivo para validar sua formatao e seu contedo. Caso algum erro seja
encontrado no arquivo, o mesmo no estar apto a ser integrado no sistema.

82

Ento ser apresentando uma tela com os erros, conforme apndice D. No

caso do arquivo no apresentar erros, o sistema far a verificao dos valores
dos fretes, sendo que se tudo estiver correto, respeitando o parmetro de
tolerncia, ser apresenta uma tela com os detalhes do arquivo para
conferncia e habilita o boto GERAR (ver apndice E), que ao ser acionado
ir executar o processo de integrao dos conhecimentos. Mas caso algum
valor esteja fora dos parmetros especificados uma tela mostrar qual nota
est com o erro (destacando a linha em vermelho riscado) conforme apndice
F.
Em Consulta coletas, pode-se pesquisar as cargas ainda no faturas
para visualizar os detalhes da mesma, ver apndice G.
A opo Conhecimento de Frete ser utilizada pelos fornecedores
que no estiverem utilizando a integrao via arquivo EDI, ou que tenha algum
arquivo com problema e no consiga resolver em seu sistema. Pois nesta, o
portal apresenta as cargas (ver apndice H), onde ao acionar o boto Monta
Conhecimento, sero apresentadas todas as notas fiscais. Ento seleciona a
nota ou as notas do conhecimento, preenchendo os campos no cabealho
referente ao conhecimento (ver apndice I) e pressionar o boto Gerar
Conhecimento, o portal ir integrar este ao sistema.

3.5 Definio do web service integrado ao ERP Microsiga Protheus

Como para desenvolver este projeto foram utilizadas as ferramentas

do ERP Microsiga Protheus 8, ser necessrio uma breve apresentao de
como o IDE e a linguagem ADVPL permitem a criao dos web services.

83

Descrevemos abaixa alguns dos principais comandos, definidos na linguagem

ADVPL para a implementao de um web service:
a) WSSERVICE: Declara o servio;
b) ENDWSSERVICE: Fecha o bloco de declarao do servio;
c) WSDATA: Declara os parmetros do servio;
d) WSMETHOD: Declara os mtodos do servio;
e) WSRECEIVE: Defines quais os parmetros de entrada para o
servio;
f) WSSEND: Define o retorno do servio;
g) SMBOLO (::) : Indica o prprio objeto, e utilizado para
acessar o contedo de um parmetro do mtodo;
h) WSSTRUCT: Cria uma estrutura de dados;
i) ENDWSSTRUCT: Fecha o bloco de declarao de uma
estrutura;
j) SELF: indica o prprio objeto, e pode substituir o smbolo (::).
Os web services desenvolvidos no sero publicados de forma
pblica, mas sim privada. Todos web services disponibilizados no servio do
Microsiga Protheus 8, esto listados no diretrio configurado no prprio ERP, e
acessado somente por fornecedores autorizados.

84

3.5.1 Detalhes dos Web Services

Nome do Servio

CARGADAK

Descrio

Servio responsvel por retornar os dados da carga

Mtodo

getDadosDak

Descrio

Busca dados das cargas

Parmetros

NomeWs

Nome do usurio

PassWs

Senha

transpWs

Transportador

datIniWs

Data Incio da pesquisa opcional

datFimWs

Data fim da pesquisa opcional

OpcWs

Seleciona o tipo da carga a ser retornado

(Faturada / No faturada)
Retorno

aReturn

Estrutura com os dados da carga

Nome do Servio

CARGADETAIL

Descrio

Servio responsvel por retornar os detalhes da

carga

Mtodo

getDetailDai

Descrio

Busca as notas fiscais das cargas j faturadas ou os

pedidos das no faturadas, conforme o parmetro
(OpcWs)
Parmetros

NomeWs

Nome do usurio

PassWs

Senha

cargaWs

Cdigo da carga

seqCarWs

Seqncia da carga
Retorno

aReturn

Estrutura contendo os itens da carga

85

Nome do Servio

USRFRETE

Descrio

Servio responsvel por verificar a permisso de

cada transportadora no portal do frete

Mtodo

getPermissao

Descrio

validar o acesso do fornecedor de logstica ao portal

Parmetros

NomeWs

Nome do usurio

PassWs

Senha

fornecWs

Identificao do fornecedor
Retorno

transpWs

Retorna o cdigo da transportadora deste fornecedor

Nome do Servio

GERAARQDAK

Descrio

Servio responsvel por gerar o arquivo de dados

da Carga (TXT ou XML)

Mtodo 1

geraArqTxt

Descrio

Gera o arquivo seguindo as regras do formato TXT

previamente definido
Parmetros

NomeWs

Nome do usurio

PassWs

Senha

cargaWs

Cdigo da Carga
Retorno

cReturn

Indica se o arquivo foi enviado ou no por e-mail

Mtodo 2

geraArqXML

Descrio

Gera o arquivo seguindo as regras do formato XML

previamente definido pela DTD
Parmetros

NomeWs

Nome do usurio

PassWs

Senha

cargaWs

Cdigo da Carga

86

Retorno
cReturn

Indica se o arquivo foi enviado ou no por e-mail

Nome do Servio

VALIDASEC

Descrio

Efetua a Validao Secundria do arquivo de frete,

confirme descrito na definio do layout

Mtodo

getValida

Descrio
Parmetros
NomeWs

Nome do usurio

PassWs

Senha

CnpjtWs

CNPJ do Transportador

CnpjfWs

CNPJ da Filial de Faturamento onde as notas fiscais

foram coletadas

DadosWs

Array contendo os dados do arquivo para validao

Retorno

aReturn

Estrutura com as notas fiscais validadas e indicando

se valores esto iguais ou divergentes

3.5.2 Exemplo de um servio de web service em ADVPL

Para apresentar os web services, foi selecionado o servio

CARGADAK. Possui um nico mtodo chamado, getDadosDak, e possui como
parmetro, nome, senha, cdigo do transportador, data incio e data fim para a
pesquisa e um parmetro que indica se devem retornar as cargas j faturadas
ou as ainda no faturadas, pois este servio ser utilizado em mais de uma
rotina no portal.
Este servio busca as cargas do fornecedor de transporte logstico.
O retorno deste servio ser uma estrutura, tipo matriz, contendo: Cdigo da
carga, Tipo do frete, Tipo do veculo, Data da montagem da carga, Data da
coleta, Cidade destino, Placa do caminho, Motorista, Peso da carga.

87

Quando um web service compilado no IDE e desenvolvido em

ADVPL, este ir gerar seu respectivo arquivo WSDL e publicando-o no servidor
do Microsiga Protheus 8.
Abaixo, segue o cdigo fonte do servio desenvolvido em ADVPL:
#INCLUDE 'PROTHEUS.CH'
#INCLUDE 'APWEBSRV.CH'
#INCLUDE "RWMAKE.CH"
#INCLUDE "TOPCONN.CH"
WSSERVICE CARGADAK Description "Servico responsavel por retornar os dados da carga"
WSDATA NomeWs
as String
WSDATA PassWs
as String
WSDATA transpWs
as String
WSDATA datIniWs
as String Optional
WSDATA datFimWs
as String Optional
WSDATA aReturn
as Struct
WSDATA OpcWs
as integer
WSMETHOD getDadosDak Description "Retorna os dados da Tabela Dak"
ENDWSSERVICE
WSMETHOD getDadosDak WSRECEIVE
NomeWs,PassWs,transpWs,datIniWs,datFimWs,OpcWs WSSEND aReturn WSSERVICE
CARGADAK
Local lReturn := .T.
Local aArray := {}
Local cNome := ::NomeWs
Local cPass := ::PassWs
Local cTransp := ::transpWs
Local cDataIni := ::datIniWs
Local cDataFim := ::datFimWs
Local nOpc := ::OpcWs
Local nCont := 0
Local cQuery := ""
conout("Operacao a ser executada: " + Str(nOpc))
::aReturn:dados := {}
If Empty(cDataIni)
dDataIni := dDataBase - 5
Else
dDataIni := cToD(cDataIni)
End
If Empty(cDataFim)
dDataFim := dDataBase
Else
dDataFim := cToD(cDataFim)
End
cQuery := " Select DAK_FILIAL , DAK_COD, DAK_TIPFRE, DAK_TIPVEI, DAK_DATA,
DAK_DATCOL, DAK_DESTIN, DAK_CAMINH, DAK_MOTORI, DAK_PESO, DAK_SEQCAR "
cQuery += " FROM " + retSqlName("DAK")
cQuery += " WHERE DAK_DATA >= '" + DToS(dDataIni) + "' "
cQuery += " AND DAK_DATA <= '" + DToS(dDataFim) + "' "

88

cQuery += " AND

cQuery += " AND
cQuery += " AND

DAK_FILIAL = '" + xFilial("DAK") + "' "

DAK_TRANSP = '" + cTransp
+ "' "
D_E_L_E_T_ != '*'"

If Select("Qry") <> 0
Qry->(dbCloseArea())
End
TCQuery cQuery Alias Qry New
TcSetField("Qry" , "DAK_DATA" , "D" , 08,00)
TcSetField("Qry" , "DAK_DATCOL" , "D" , 08,00)
If Qry->(Eof())
SetSoapFault("ERRO LISTA","Nenhum dado encontrado nesse periodo!")
Return .f.
end
DAI->(DBSETORDER(1))
While Qry->(!Eof())
DAI->(DBSEEK(Qry->DAK_FILIAL + Qry->DAK_COD + Qry->DAK_SEQCAR ) , .T. )
nSkip := 0
While DAI->(!EOF()) .And. DAI->DAI_FILIAL == Qry->DAK_FILIAL .And.
DAI->DAI_COD == Qry->DAK_COD .And.
DAI->DAI_SEQCAR == Qry->DAK_SEQCAR
If nOpc == 1 //Faturadas
If !Empty(DAI->DAI_NFISCA)
nSkip ++
End
ElseIf nOpc == 2 //Nao Faturadas
If !Empty(DAI->DAI_NFISCA)
nSkip ++
End
End
DAI->(DBSKIP())
End
conout(nSkip)
If nSkip == 0 .And. nOpc == 2
nCont ++
AAdd( ::aReturn:dados , WSClassNew( "dadosDak" ) )
//Alimentando campos de retorno do Ws
::aReturn:dados[ nCont ]:CODIGO := Qry->DAK_COD
::aReturn:dados[ nCont ]:TIPFRE
:= Qry->DAK_TIPFRE
::aReturn:dados[ nCont ]:TIPVEI
:= Qry->DAK_TIPVEI
::aReturn:dados[ nCont ]:DATMON
:= dToC(Qry->DAK_DATA)
::aReturn:dados[ nCont ]:DATCOL
:= dToC(Qry->DAK_DATCOL)
::aReturn:dados[ nCont ]:DESTIN
:= Qry->DAK_DESTIN
::aReturn:dados[ nCont ]:PLACA
:= Qry->DAK_CAMINH
::aReturn:dados[ nCont ]:MOTORI
:= Qry->DAK_MOTORI
::aReturn:dados[ nCont ]:PESO := Transform(Qry->DAK_PESO ,
X3Picture("DAK_PESO"))
::aReturn:dados[ nCont ]:SEQCAR
:= Qry->DAK_SEQCAR
ElseIf nSkip > 0 .And. nOpc == 1
nCont ++
AAdd( ::aReturn:dados , WSClassNew( "dadosDak" ) )
//Alimentando campos de retorno do Ws
::aReturn:dados[ nCont ]:CODIGO := Qry->DAK_COD
::aReturn:dados[ nCont ]:TIPFRE
:= Qry->DAK_TIPFRE
::aReturn:dados[ nCont ]:TIPVEI
:= Qry->DAK_TIPVEI

89

::aReturn:dados[ nCont ]:DATMON

:= dToC(Qry->DAK_DATA)
::aReturn:dados[ nCont ]:DATCOL
:= dToC(Qry->DAK_DATCOL)
::aReturn:dados[ nCont ]:DESTIN
:= Qry->DAK_DESTIN
::aReturn:dados[ nCont ]:PLACA
:= Qry->DAK_CAMINH
::aReturn:dados[ nCont ]:MOTORI
:= Qry->DAK_MOTORI
::aReturn:dados[ nCont ]:PESO := Transform(Qry->DAK_PESO ,
X3Picture("DAK_PESO"))
::aReturn:dados[ nCont ]:SEQCAR
:= Qry->DAK_SEQCAR

End

End
Qry->(DBSKIP())

Return lReturn
WSSTRUCT Struct
WSDATA dados as Array Of dadosDak optional
EndWsStruct
WSSTRUCT dadosDak
WSDATA CODIGO
WSDATA TIPFRE
WSDATA TIPVEI
WSDATA DATMON
WSDATA DATCOL
WSDATA DESTIN
WSDATA PLACA
WSDATA MOTORI
WSDATA PESO
WSDATA SEQCAR
EndWsStruct

as String OPTIONAL
as String OPTIONAL
as String OPTIONAL
as String OPTIONAL
as String OPTIONAL
as String OPTIONAL
as String OPTIONAL
as String OPTIONAL
as String OPTIONAL
as String OPTIONAL

3.5.3 Documento WSDL

Este arquivo gerado automaticamente e publicado durante o

processo de compilao do web service. Contm todas as informaes
necessrias para a criao do cliente do web service, independente de
plataforma e linguagem de programao. Abaixo segue o arquivo WSDL do
web service CARGADAK.

<?xml version="1.0" encoding="utf-8" ?>

<!--Generated 20060616 10:16 by ADVPL WSDL Server 1.060117 / Protheus 7.00.051130P-->
<definitions xmlns:http=http://schemas.xmlsoap.org/wsdl/http/
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:s="http://www.w3.org/2001/XMLSchema"
xmlns:s0="http://192.168.0.11:8080/"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/"

90

xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
targetNamespace="http://192.168.0.11:8080/"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<types>
<s:schema elementFormDefault="qualified" targetNamespace="http://192.168.0.11:8080/">
<s:element name="GETDADOSDAK">
<s:complexType>
<s:sequence>
<s:element minOccurs="1" maxOccurs="1" name="NOMEWS" type="s:string" />
<s:element minOccurs="1" maxOccurs="1" name="PASSWS" type="s:string" />
<s:element minOccurs="1" maxOccurs="1" name="TRANSPWS" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="DATINIWS" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="DATFIMWS" type="s:string" />
<s:element minOccurs="1" maxOccurs="1" name="OPCWS" type="s:integer" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="GETDADOSDAKRESPONSE">
<s:complexType>
<s:sequence>
<s:element minOccurs="1" maxOccurs="1" name="GETDADOSDAKRESULT"
type="s0:STRUCT" />
</s:sequence>
</s:complexType>
</s:element>
<s:complexType name="STRUCT">
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="DADOS"
type="s0:ARRAYOFDADOSDAK"/>
</s:sequence>
</s:complexType>
<s:complexType name="DADOSDAK">
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="CODIGO" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="DATCOL" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="DATMON" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="DESTIN" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="MOTORI" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="PESO" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="PLACA" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="SEQCAR" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="TIPFRE" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="TIPVEI" type="s:string" />
</s:sequence>
</s:complexType>
<s:complexType name="ARRAYOFDADOSDAK">
<s:sequence>
<s:element minOccurs="0" maxOccurs="unbounded" name="DADOSDAK"
type="s0:DADOSDAK" />
</s:sequence>
</s:complexType>
</s:schema>
</types>
<message name="GETDADOSDAKSOAPIN">
<part name="parameters" element="s0:GETDADOSDAK" />
</message>
<message name="GETDADOSDAKSOAPOUT">
<part name="parameters" element="s0:GETDADOSDAKRESPONSE" />
</message>
<portType name="CARGADAKSOAP">

91

<operation name="GETDADOSDAK">
<documentation>Retorna os dados da Tabela Dak</documentation>
<input message="s0:GETDADOSDAKSOAPIN" />
<output message="s0:GETDADOSDAKSOAPOUT" />
</operation>
</portType>
<binding name="CARGADAKSOAP" type="s0:CARGADAKSOAP">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" />
<operation name="GETDADOSDAK">
<soap:operation soapAction=http://192.168.0.11:8080/GETDADOSDAK
style="document" />
<input>
<soap:body use="literal" />
</input>
<output>
<soap:body use="literal" />
</output>
</operation>
</binding>
<service name="CARGADAK">
<documentation>Servico responsavel por retornar os dados da carga</documentation>
<port name="CARGADAKSOAP" binding="s0:CARGADAKSOAP">
<soap:address location="http://192.168.0.11:8080/ws/CARGADAK.apw" />
</port>
</service>
</definitions>

3.5.4 Exemplo de um cliente de web service em ADVPL

A ferramenta IDE, possui um assistente que gera automaticamente o

cliente web service simplesmente informando a URL (endereo eletrnico) do
arquivo WSDL. No necessariamente este tem que ter sido gerado em ADVPL,
mas qualquer web service que tenha sua especificao WSDL e publicado em
algum diretrio pblico ou no. Abaixo est o fonte gerado pela ferramenta IDE
para o cliente do web service CARGADAK.
#INCLUDE "PROTHEUS.CH"
#INCLUDE "APWEBSRV.CH"
/*======================================================================
WSDL Location http://192.168.0.11:8080/ws/CARGADAK.apw?WSDL
Gerado em
06/14/06 11:59:14
Observaes
Cdigo-Fonte gerado por ADVPL WSDL Client 1.060117
Alteraes neste arquivo podem causar funcionamento incorreto
e sero perdidas caso o cdigo-fonte seja gerado novamente.
====================================================================== */

92

User Function _JMVJOZP ; Return // "dummy" function - Internal Use

/* ------------------------------------------------------------------------------WSDL Service WSCARGADAK
------------------------------------------------------------------------------- */
WSCLIENT WSCARGADAK
WSMETHOD NEW
WSMETHOD INIT
WSMETHOD RESET
WSMETHOD CLONE
WSMETHOD GETDADOSDAK
WSDATA
WSDATA
WSDATA
WSDATA
WSDATA
WSDATA
WSDATA
WSDATA

_URL
cNOMEWS
cPASSWS
cTRANSPWS
cDATINIWS
cDATFIMWS
nOPCWS
oWSGETDADOSDAKRESULT

AS String
AS string
AS string
AS string
AS string
AS string
AS integer
AS CARGADAK_STRUCT

ENDWSCLIENT
WSMETHOD NEW WSCLIENT WSCARGADAK
::Init()
If !FindFunction("XMLCHILDEX")
UserException("O Cdigo-Fonte Client atual requer os executveis do Protheus Build
[7.00.051130P] ou superior. Atualize o Protheus ou gere o
Cdigo-Fonte novamente utilizando o Build atual.")
EndIf
Return Self
WSMETHOD INIT WSCLIENT WSCARGADAK
::oWSGETDADOSDAKRESULT := CARGADAK_STRUCT():New()
Return
WSMETHOD RESET WSCLIENT WSCARGADAK
::cNOMEWS
:= NIL
::cPASSWS
:= NIL
::cTRANSPWS
:= NIL
::cDATINIWS
:= NIL
::cDATFIMWS
:= NIL
::nOPCWS
:= NIL
::oWSGETDADOSDAKRESULT
:= NIL
::Init()
Return
WSMETHOD CLONE WSCLIENT WSCARGADAK
Local oClone := WSCARGADAK():New()
oClone:_URL
:= ::_URL
oClone:cNOMEWS
:= ::cNOMEWS
oClone:cPASSWS
:= ::cPASSWS
oClone:cTRANSPWS := ::cTRANSPWS
oClone:cDATINIWS
:= ::cDATINIWS
oClone:cDATFIMWS := ::cDATFIMWS
oClone:nOPCWS
:= ::nOPCWS
oClone:oWSGETDADOSDAKRESULT := IIF(::oWSGETDADOSDAKRESULT = NIL ,
NIL ,::oWSGETDADOSDAKRESULT:Clone() )

93

Return oClone
/* ------------------------------------------------------------------------------WSDL Method GETDADOSDAK of Service WSCARGADAK
------------------------------------------------------------------------------- */
WSMETHOD GETDADOSDAK WSSEND
cNOMEWS,cPASSWS,cTRANSPWS,cDATINIWS,cDATFIMWS,nOPCWS WSRECEIVE
oWSGETDADOSDAKRESULT WSCLIENT WSCARGADAK
Local cSoap := "" , oXmlRet
BEGIN WSMETHOD
cSoap += '<GETDADOSDAK xmlns="http://192.168.0.11:8080/">'
cSoap += WSSoapValue("NOMEWS", ::cNOMEWS, cNOMEWS , "string", .T. , .F., 0 )
cSoap += WSSoapValue("PASSWS", ::cPASSWS, cPASSWS , "string", .T. , .F., 0 )
cSoap += WSSoapValue("TRANSPWS", ::cTRANSPWS, cTRANSPWS , "string", .T. , .F., 0 )
cSoap += WSSoapValue("DATINIWS", ::cDATINIWS, cDATINIWS , "string", .F. , .F., 0 )
cSoap += WSSoapValue("DATFIMWS", ::cDATFIMWS, cDATFIMWS , "string", .F. , .F., 0 )
cSoap += WSSoapValue("OPCWS", ::nOPCWS, nOPCWS , "integer", .T. , .F., 0 )
cSoap += "</GETDADOSDAK>"
oXmlRet := SvcSoapCall(
Self,cSoap,;
"http://192.168.0.11:8080/GETDADOSDAK",;
"DOCUMENT","http://192.168.0.11:8080/",,"1.031217",;
"http://192.168.0.11:8080/ws/CARGADAK.apw")
::Init()
::oWSGETDADOSDAKRESULT:SoapRecv( WSAdvValue(
oXmlRet,"_GETDADOSDAKRESPONSE:_GETDADOSDAKRESULT","STRUCT",NIL,NIL,NIL,
NIL,NIL) )
END WSMETHOD
oXmlRet := NIL
Return .T.
/* ------------------------------------------------------------------------------WSDL Data Structure STRUCT
------------------------------------------------------------------------------- */
WSSTRUCT CARGADAK_STRUCT
WSDATA oWSDADOS
OPTIONAL
WSMETHOD NEW
WSMETHOD INIT
WSMETHOD CLONE
WSMETHOD SOAPRECV
ENDWSSTRUCT

AS CARGADAK_ARRAYOFDADOSDAK

WSMETHOD NEW WSCLIENT CARGADAK_STRUCT

::Init()
Return Self
WSMETHOD INIT WSCLIENT CARGADAK_STRUCT
Return
WSMETHOD CLONE WSCLIENT CARGADAK_STRUCT
Local oClone := CARGADAK_STRUCT():NEW()

94

oClone:oWSDADOS
Return oClone

:= IIF(::oWSDADOS = NIL , NIL , ::oWSDADOS:Clone() )

WSMETHOD SOAPRECV WSSEND oResponse WSCLIENT CARGADAK_STRUCT

Local oNode1
::Init()
If oResponse = NIL ; Return ; Endif
oNode1 := WSAdvValue(
oResponse,"_DADOS","ARRAYOFDADOSDAK",NIL,NIL,NIL,"O",NIL)
If oNode1 != NIL
::oWSDADOS := CARGADAK_ARRAYOFDADOSDAK():New()
::oWSDADOS:SoapRecv(oNode1)
EndIf
Return
/* ------------------------------------------------------------------------------WSDL Data Structure ARRAYOFDADOSDAK
------------------------------------------------------------------------------- */
WSSTRUCT CARGADAK_ARRAYOFDADOSDAK
WSDATA oWSDADOSDAK
AS CARGADAK_DADOSDAK OPTIONAL
WSMETHOD NEW
WSMETHOD INIT
WSMETHOD CLONE
WSMETHOD SOAPRECV
ENDWSSTRUCT
WSMETHOD NEW WSCLIENT CARGADAK_ARRAYOFDADOSDAK
::Init()
Return Self
WSMETHOD INIT WSCLIENT CARGADAK_ARRAYOFDADOSDAK
::oWSDADOSDAK
:= {} // Array Of CARGADAK_DADOSDAK():New()
Return
WSMETHOD CLONE WSCLIENT CARGADAK_ARRAYOFDADOSDAK
Local oClone := CARGADAK_ARRAYOFDADOSDAK():NEW()
oClone:oWSDADOSDAK := NIL
If ::oWSDADOSDAK <> NIL
oClone:oWSDADOSDAK := {}
aEval( ::oWSDADOSDAK , { |x| aadd( oClone:oWSDADOSDAK , x:Clone() ) } )
Endif
Return oClone
WSMETHOD SOAPRECV WSSEND oResponse WSCLIENT
CARGADAK_ARRAYOFDADOSDAK
Local nRElem1, oNodes1, nTElem1
::Init()
If oResponse = NIL ; Return ; Endif
oNodes1 := WSAdvValue(
oResponse,"_DADOSDAK","DADOSDAK",{},NIL,.T.,"O",NIL)
nTElem1 := len(oNodes1)
For nRElem1 := 1 to nTElem1
If !WSIsNilNode( oNodes1[nRElem1] )
aadd(::oWSDADOSDAK , CARGADAK_DADOSDAK():New() )

Return

::oWSDADOSDAK[len(::oWSDADOSDAK)]:SoapRecv(oNodes1[nRElem1])
Endif
Next

95

/* ------------------------------------------------------------------------------WSDL Data Structure DADOSDAK

------------------------------------------------------------------------------- */
WSSTRUCT CARGADAK_DADOSDAK
WSDATA cCODIGO
AS string OPTIONAL
WSDATA cDATCOL
AS string OPTIONAL
WSDATA cDATMON
AS string OPTIONAL
WSDATA cDESTIN
AS string OPTIONAL
WSDATA cMOTORI
AS string OPTIONAL
WSDATA cPESO
AS string OPTIONAL
WSDATA cPLACA
AS string OPTIONAL
WSDATA cSEQCAR
AS string OPTIONAL
WSDATA cTIPFRE
AS string OPTIONAL
WSDATA cTIPVEI
AS string OPTIONAL
WSMETHOD NEW
WSMETHOD INIT
WSMETHOD CLONE
WSMETHOD SOAPRECV
ENDWSSTRUCT
WSMETHOD NEW WSCLIENT CARGADAK_DADOSDAK
::Init()
Return Self
WSMETHOD INIT WSCLIENT CARGADAK_DADOSDAK
Return
WSMETHOD CLONE WSCLIENT CARGADAK_DADOSDAK
Local oClone := CARGADAK_DADOSDAK():NEW()
oClone:cCODIGO
:= ::cCODIGO
oClone:cDATCOL
:= ::cDATCOL
oClone:cDATMON
:= ::cDATMON
oClone:cDESTIN
:= ::cDESTIN
oClone:cMOTORI
:= ::cMOTORI
oClone:cPESO
:= ::cPESO
oClone:cPLACA
:= ::cPLACA
oClone:cSEQCAR
:= ::cSEQCAR
oClone:cTIPFRE
:= ::cTIPFRE
oClone:cTIPVEI
:= ::cTIPVEI
Return oClone
WSMETHOD SOAPRECV WSSEND oResponse WSCLIENT CARGADAK_DADOSDAK
::Init()
If oResponse = NIL ; Return ; Endif
::Ccodigo
:= WSAdvValue( oResponse,"_CODIGO","string",NIL,NIL,NIL,"S",NIL)
::cDATCOL := WSAdvValue( oResponse,"_DATCOL","string",NIL,NIL,NIL,"S",NIL)
::cDATMON := WSAdvValue( oResponse,"_DATMON","string",NIL,NIL,NIL,"S",NIL)
::cDESTIN := WSAdvValue( oResponse,"_DESTIN","string",NIL,NIL,NIL,"S",NIL)
::cMOTORI := WSAdvValue( oResponse,"_MOTORI","string",NIL,NIL,NIL,"S",NIL)
::cPESO
:= WSAdvValue( oResponse,"_PESO","string",NIL,NIL,NIL,"S",NIL)
::cPLACA
:= WSAdvValue( oResponse,"_PLACA","string",NIL,NIL,NIL,"S",NIL)
::cSEQCAR := WSAdvValue( oResponse,"_SEQCAR","string",NIL,NIL,NIL,"S",NIL)
::cTIPFRE := WSAdvValue( oResponse,"_TIPFRE","string",NIL,NIL,NIL,"S",NIL)
::cTIPVEI
:= WSAdvValue( oResponse,"_TIPVEI","string",NIL,NIL,NIL,"S",NIL)
Return

96

4 CONCLUSO

Buscando atingir o objetivo traado no incio do projeto, buscou-se

fundamentao variada e tambm recente, atravs de revistas e sites
especializados.
Durante o desenvolvimento do trabalho podem-se observar as
vantagens da padronizao das tecnologias. Principalmente durante o uso das
ferramentas utilizadas para a criao dos web services com a utilizao dos
arquivos WSDL. Verificou-se que estes transcendem a teoria e se mostram
muito teis e necessrios na prtica.
Por meio da construo do portal para o fornecedor de logstica,
conseguiu-se agregar valor ao processo. Foi mesclando novas tecnologias
como web service com a tecnologia j reconhecida e validada como o EDI, que
possibilitou a realizao dos objetivos propostos.
O projeto trouxe ao fornecedor reduo de custos e agilidade
necessria para liberao das cargas para viagem, por meio da eliminao da
digitao das notas e a automatizao do encaminhamento dos conhecimentos
de frete ao cliente.
J a empresa se beneficia com a reduo dos processos de
lanamento dos conhecimentos de frete e da gerao de fatura. Alm de liberar
os profissionais para outras atividades, reduz o volume de retrabalho causado
por erros de digitao devido ao alto volume de conhecimentos processados.
Obteve ganho tambm pela facilidade de gerenciamento e na transparncia
obtida sobre aos valores pagos pelo servio de transporte, pois a informao

97

ser disponibilizada a todos no momento da gerao do faturamento,

possibilitando assim a conferncia dos valores automaticamente no momento
em que o fornecedor integrar os dados ao sistema, alm de melhor o nvel de
detalhamento da informao.
Desta forma conclui-se que as empresas devem buscar tecnologias,
muitas j disponveis, porm pouco exploradas, para modernizar e automatizar
quando possvel seus processos. E que a integrao entre clientes e
fornecedores j se mostrou ser algo factvel e muito interessante para ambos.
Como sugesto para trabalhos futuros, cita-se uma utilizao mais
especfica para os web services. Fazendo com que os dados sejam integrados
entre os sistemas do cliente e do fornecedor, sem a necessidade de utilizar o
EDI, mas sim por meio de servios disponibilizados em ambos os sistemas
com o uso dos web services.

98

REFERNCIAS

ALBERTIN, Alberto Luiz. Comrcio Eletrnico: modelo, aspectos e

contribuies de sua aplicao. So Paulo: Atlas, 2002. 292 p.
ANDERSON, Richard et al. Professional XML, Rio de Janeiro: Cincia
Moderna Ltda, 2001, 1266 p.
CUNHA, Davi. Web Services, SOAP e Aplicaes Web. Disponvel em
<http://devedge-temp.mozilla.org/viewsource/2002/soapoverview/index_pt_br.html>. Acessado em 16 maio 2006.
CZERVENY, Arno. Web Services: Onde estamos e para onde vamos.
Revista Mundo Java, Ano I n 02, Mundo OO, Rio de Janeiro, RJ. 2004.
DEITEL, H.M.; DEITEL, P.J.; NIETO, T.R.; LIN, T.M.; SADHU, P. XML Como
programar traduo de Luiz Augusto Salgado e Edson Furmankiewicz. Porto
Alegre: Bookman, 2003.
DIAS, Marco Aurlio P. Administrao de Materiais. So Paulo: Atlas, 1985.
FRANCO JR., Carlos F. E-business:tecnologia da informao e negcios na
Internet. 4.ed. So Paulo: Atlas, 2001. 281 p.
GALVIN, Deleon. Prottipo de Sistema CRM para Dispositivos Mveis
utilizando a Tecnologia.Net. Blumenau, SC: Universidade Regional de
Blumenau, 2004. Rio de Janeiro, RJ: PUC, 2004.
KOEHNE, Michael. XML-Edifact. Disponvel em <http://www.xmledifact.org/TR/NOTE-xml-edifact.html>. Acessado em 11 maio de 2006.
NATANYA, Pitts Moultis; CHERYL, Kirk. XML Black Book: solues e poder,
traduo de Ariovaldo Griesi, So Paulo: Makron Books, 2000.
NIELSEN, Jakob. Projetando websites, Traduo de Ana Gibson. Rio de
Janeiro: Campos, 2000. 416 p.

99

NIELSEN, Jakob; TAHIR, Marie. Homepage: 50 websites desconstruidos,

Traduo de Tereza Cristina Felix de Souza. Rio de Janeiro: Campos, 2002.
314 p.
OBRIEN, James A. Sistemas de Informao e as decises gerenciais na
era da Internet, traduo de Clio Knipel Moreira e Cid Knipel Moreira. 2 ed,
So Paulo: Saraiva, 2004.
PAULON, Renan. Web Services in JAVA. Disponvel em:
<http://www.imasters.com.br/artigo/1863>. Acesso em 08 maio 2006.
PAULON, Renan. Soap Attachments com Axis. Disponvel em:
<http://www.imasters.com.br/artigo/3879/xml/soap_attachments_com_axis>.
Acesso em 09 maio 2006.
POTTS, Stephen; KOPACK, Mike. Aprenda Web services em 24 horas,
traduo de Marcos Vieira. Rio de Janeiro: Campus, 2003. 367 p.
W3C, Extensible Markup Language (XML). Disponvel em
<http://www.w3.org/XML>. Acessado em 16 maio 2006.
W3C, Extensible Markup Language (XML) 1.0 (Third Edition), Disponvel em
<http://www.w3.org/TR/2004/REC-xml-20040204/#sec-intro>. Acessado em 12
maio 2006.
ZAVALIK, Claudimir; LACERDA, Guilherme; OLIVEIRA, Jos Palazzo M.de.
Implementando Web Services com Software Livre. Disponvel em
< http://www.palazzo.pro.br/artigos/04%20Software%20Livre%20%20Web%20Serv.htm >. Acessado em 07 Jun. 2006.

100

REFERNCIAS COMPLEMENTARES

MACORATTI, Jos Carlos. Web Services, tendncia ou moda?. Disponvel

em <http://www.macoratti.net/wbs_1.htm>, Acessado em 07 de junho, 00:55h.
MENDES, Fernando Vasconcelos, Desvendando Web Services (Soap/XML).
Disponvel em: <http://www.delphibr.com.br/artigos/soap.php> Acessado em
18 jun. 2004.
NARDON, Fabiane Bizinella. Utilizando XML para representao de
informao em Sade, Unidade de Pesquisa e Desenvolvimento Instituto do
Corao do Hospital das Clnicas da Faculdade de Medicina da USP. So
Paulo SP
Palm Inc, White Paper: Integrating Mobile Data Services into Enterprise
Infrastructures, 2003.
SUCUPIRA, Cezar. E-PROCUREMENT:Consideraes sobre a boa e a m
utilizao desta nova facilidade proporcionada pela Internet, Disponvel em
<http://www.cezarsucupira.com.br/artigos9.htm>. Acesso em 15 Jun. 2006.
WESCHENFELDER .Marcel Felipe; MUSA, Daniela Leal ; OLIVEIRA, Jos
Palazzo M. de. Comportamento Ativo em Web services. Instituto de
Informtica Universidade Federal do Rio Grande do Sul (UFRGS), Porto
Alegre RS.
W3SCHOOLS. Introduction to XML Introduction to XML. Disponvel em
<http://www.w3schools.com/xml/xml_whatis.asp>. Acessado em 12 maio 2006.

101

APNDICES

APNCIDE A Tela de login do portal

102

APNCIDE B Tela de consulta cargas faturadas (opo Consulta de Cargas)

103

APNDICE C Tela de solicitao do caminho e arquivo para integrao dos

conhecimentos (opo Validao)

104

APNCIDE D Tela dos erros encontrados no arquivo (Opo Validao)

105

APNCIDE E Tela de Integrao do arquivo validado e pronto para gerao

(opo Validao)

106

APNCIDE F Tela de integrao apresentando valor de frete fora dos

parmetros especificados (opo Validao)

107

APNCIDE G Tela de consulta de cargas ainda no faturadas (opo

Consulta Cargas)

108

APNCIDE H Tela de consulta cargas para gerao do conhecimento

manual (opo Conhecimento de Frete)

109

APNCIDE I Tela de preenchimento dos dados do conhecimento e seleo

das notas fiscais (opo Conhecimento de Frete)

APNCIDE J Formulrio aplicado na pesquisa (enviado por e-mail)

110

TEMA: EDI - Integrao com fornecedores de logstica. Aplicado empresa Anjo

Qumica com o ERP da Microsiga.
Este questionrio tem o objetivo de fornecer um perfil das tecnologias utilizadas
pelos clientes usurios do ERP da Microsiga (Franquia Santa Catarina regional
SUL). Estes dados serviro compilados e utilizados em minha monografia para
concluso do MBA - Banco de Dados realizado na UNESC - Universidade do
extremo Sul Catarinense
O formulrio no possui identificao para garantir a privacidade dos dados, e em
momento algum estes dados sero relacionados com a empresa que o respondeu.
Este questionrio composto somente de 14 perguntas e acredito que no tomara
mais que 5 minutos de seu tempo.
Agradeo desde j o tempo dispensado no preenchimento deste questionrio.
Instrues de preenchimento:
As respostas de nica escolha utilizam campos do tipo formulrio suspenso (list
Box), e as respostas de mltipla escolha utilizam os campos tipo caixa de seleo.
Caso alguma pergunta no puder ser respondida, pode ser deixada sem preencher
nos tipo mltipla escolha ou com o contedo sem resposta nas de nica escolha.

Questionrio:
1) H quanto tempo empresa utiliza o ERP?
R: sem resposta
2) Quais reas da Empresa j se utilizam os recursos do ERP?
a.
Comercial
b.
Financeiro
c.
Produo
d.
Recursos Humanos
e.
Projetos
f.
Logstica
g.
Contabilidade/Fiscal
h.
Manuteno
i.
SAC / Ps-Vendas
j.
Outras
3) O Que motivou a implantao do ERP?
a.
Sistema legado no integrado.
b.
Bug do milnio
c.
Reduo da equipe interna da informtica
d.
Aumentar a disponibilidade de informaes alta administrao
e.
Outro
4) Qual a estimativa de gastos anuais com manuteno e customizaes?
R: sem resposta

111

5) Alm do ERP que outras tecnologias so utilizadas para auxiliar nos negcios da
empresa?
a.
E-mail
b.
Workflow
Sistemas de Fora de Venda
c.
d.
Sistemas para CRM (Customer Relationship Manager)
e.
Sistemas BI (Business Inteligence)
EDI (Eletronic Data Interchange)
f.
g.
Outro
6) A empresa utiliza banco de dados? Qual?
a.
Oracle
MSSQL Server
b.
c.
Sybase
Postgress
d.
e.
MySql
f.
Outro
7) Quais os benefcios identificados com a utilizao do ERP?
a.
Aumento no volume de faturamento da empresa.
b.
Agilidade na obteno de Informaes.
c.
Maior confiana nas informaes.
d.
Aumento de credibilidade perante aos clientes.
e.
Integrao dos setores da empresa.
f.
Outros
8) A empresa possui algum tipo de integrao com parceiros comerciais, como:
clientes, fornecedores, representantes comerciais, agentes de exportao, etc.?
R: sem resposta
9) Existe atualmente alguma aplicao de EDI implantado na empresa?
R: sem resposta
10) Caso utilize EDI. Qual setor est utilizando?
a.
Comercial
b.
Financeiro
c.
Produo
d.
Recursos Humanos
e.
Projetos
f.
Logstica
g.
Contabilidade/Fiscal
h.
Manuteno
i.
SAC / Ps-Vendas
Outras
j.

112

11) Caso Utilize EDI. Como estes dados so integrados ao ERP?

a.
Interface disponibilizada na Internet.
E-mail em formato especial processado pelo ERP.
b.
c.
Planilha Excel
d.
Arquivo TEXTO (padronizado)
Arquivo XML
e.
f.
Outros
12) Existe atualmente Web Services implantados na empresa?
R: sem resposta
13) Caso utilize Web Services para qual aplicao est sendo utilizado?
a.
Integrao de Base Interna
Integrao de Base de Cliente/Fornecedor
b.
c.
Para Consulta de Dados.
14) A empresa possui algum site (Portal) para realizao de negcios com os
fornecedores ou cliente?
R: sem resposta

113

APNCIDE K Tabulao dos resultados da Pesquisa

1

H quanto tempo empresa utiliza o ERP?

a
b
c
d
e

1 ano
2 anos
2 a 5 anos
6 a 10 anos
mais 10 anos

x x
x

x
x x

x
x

x
x

x
x x x

x x
x x

Quais reas da Empresa j se utilizam os recursos do ERP?

a Comercial
b Financeiro
c Produo
d Recursos Humanos

x
x
x
x

x
x
x
x

x
x
x
x

x
x
x
x

x
x
x
x

x
x
x
x

x
x x
x x x x
x
x x
x x x x

x
x
x
x

x
x
x
x

x
x
x
x

x
x
x
x

x
x
x
x

x
x
x
x

x
x x
x
x x

e Projetos
f Logstica
g Contabilidade/Fiscal
h Manuteno

x
x
x

x
x x x x x x
x
x x

i SAC / Ps-Vendas

x
x x x
x
x

x
x x x x
x
x

j Outras

x x

Compras e Estoque

x
x

PLS - Plano de Sade

3

O Que motivou a implantao do ERP?

x x
x x

a Sistema legado no integrado.

b Bug do milnio
Reduo da equipe interna da
c informtica
Aumentar a disponibilidade de
d informaes alta administrao

x x

e Outro
Evoluo Tecnolgica, Integrao dos
Processos na Empresa
4

x
x

x x x x x
x

x
x

x x x x

x x x

Qual a estimativa de gastos anuais com manuteno e customizaes?

a at 25000,00
b at 50000,00
c at 100000,00
d at 250000,00
e at 500000,00
f at 1000000,00
g acima de 1000000,00

x
x

x
x

x
x

x
x

114

Alm do ERP que outras tecnologias so utilizadas para auxiliar nos negcios
da empresa?
a E-mail
b Workflow
c Sistemas de Fora de Venda
Sistemas para CRM (Customer
d Relationship Manager)

x x x x x x x x
x x
x x
x
x
x
x

e Sistemas BI (Business Inteligence)

f EDI (Eletronic Data Interchange)

x x x
x x
x

x x x x x
x x
x
x

x x

g Outro

Sistema CAD e Projetos

x
x x x

Excel, Word, Power point

6

x
x x

A empresa utiliza banco de dados? Qual?

a Oracle
b MSSQL Server

x x

x
x x x x x x

x x x x

c Sybase
d Postgress
e MySql
f Outro
DB2

Quais os benefcios identificados com a utilizao do ERP?

a Aumento no volume de faturamento
da empresa.
Agilidade na obteno de
b Informaes.
c Maior confiana nas informaes.
Aumento de credibilidade perante aos
d clientes.
e Integrao dos setores da empresa.

x x x x x
x
x x x x x x

x x x x x x x x
x x x x x x x
x

x x
x
x
x x x x x x x x x x x x x x x x x x

f Outros
8

A empresa possui algum tipo de integrao com parceiros comerciais, como: clientes,
fornecedores, representantes comerciais, agentes de exportao, etc.?
a Sim

x x

x x

x x x x x

b No
c Pretende Utilizar

x x

x
x

Existe atualmente alguma aplicao de EDI implantado na empresa?

x x

a Sim
b No
c Pretende Utilizar

x x
x

x
x x

x
x

x
x x
x

x
x x

115

10 Caso utilize EDI. Qual setor est utilizando?

x x
x x

a Comercial
b Financeiro

x
x

x
x

c Produo
d Recursos Humanos
e Projetos
f Logstica
d Contabilidade/Fiscal
e Manuteno
f SAC / Ps-Vendas
d Outras

PLS - Plano de Sade

11 Caso Utilize EDI. Como estes dados so integrados ao ERP?

a Interface disponibilizada na Internet.

E-mail em formato especial
b processado pelo ERP.

c Planilha Excel

d Arquivo TEXTO (padronizado)

e Arquivo XML
f Outros

Digitao

12 Existe atualmente Web Services implantados na empresa?

a Sim

x
x x

b No

x x

x
x

x x

c Pretende Utilizar

x x
x

13 Caso utilize Web Services para qual aplicao est sendo utilizado?
a Integrao de Base Interna
Integrao de Base de
b Cliente/Fornecedor

c Para Consulta de Dados.

x
x

x
x

14 A empresa possui algum site (Portal) para realizao de negcios com

os fornecedores ou cliente?

a Sim
b No
c Pretende Utilizar

x x x
x x

x x

x x
x x