Manual técnico de webservices COE

COE
SISTEMA DE COMPRAS ELETRÔNICAS

INTEGRAÇÃO COM OUTROS SISTEMAS
MANUAL TÉCNICO DE WEBSERVICES
Atualizado em: 01/03/2023
Praça dos Açorianos, s/n° - CEP 90010-340

Porto Alegre, RS
+55 (51) 3210-3100
http://www.procergs.rs.gov.br
COE - SISTEMA DE COMPRAS ELETRÔNICAS
Sumário
1. Objetivo..............................................................................................................................3
2. Utilização............................................................................................................................3
2.1. Disponibilidade...........................................................................................................3
2.2. Responsabilidade.......................................................................................................3
3. Características...................................................................................................................4
3.1. Versionamento............................................................................................................5
4. Implementação...................................................................................................................5
4.1. Geração de classes....................................................................................................5
4.2. Autenticação...............................................................................................................6
4.3. Autenticação descentralizada.....................................................................................6
4.4. Datas...........................................................................................................................7
4.4.1. Valores recebidos................................................................................................7
4.4.2. Valores a enviar...................................................................................................7
4.5. Certificado digital........................................................................................................8
4.6. Tabelas de conversão.................................................................................................8
4.7. Serviços......................................................................................................................8
4.7.1. Ofertas.................................................................................................................9
4.7.1.1. Criar..............................................................................................................9
4.7.1.2. Anexar........................................................................................................12
4.7.1.3. Publicar......................................................................................................13
4.7.1.4. Remover.....................................................................................................14
4.7.1.5. Consultar....................................................................................................15
4.7.1.6. Cancelar.....................................................................................................27
4.7.1.7. Homologar..................................................................................................27
4.7.1.8. Desfazer fase.............................................................................................28
4.7.2. Credenciados....................................................................................................29
4.7.2.1. Consultar....................................................................................................29
4.7.2.2. Criar............................................................................................................33
4.7.2.3. Credenciar..................................................................................................37
4.7.2.4. Certificar.....................................................................................................38
4.7.2.5. Alterar.........................................................................................................38
4.7.2.6. Excluir.........................................................................................................41
4.8. Falhas.......................................................................................................................41
4.9. Testes........................................................................................................................43
5. Evolução..........................................................................................................................43
6. Contatos...........................................................................................................................43
PROCERGS – Companhia de Processamento de Dados do Rio Grande do Sul 2 / 44

Centro de Soluções em Governo Eletrônico
1. Objetivo
O objetivo deste manual é documentar os serviços web (webservices) que
possibilitam integrar o Sistema de Compras Eletrônicas (COE) com diferentes sistemas
utilizados pelos órgãos do Estado e demais entidades que negociam suas aquisições e
contratações por este sistema, estes doravante denominados de "Centrais de Compras".
Os serviços automatizam, de forma padrão, o envio de dados das ofertas a serem
cadastradas no Sistema de Compras Eletrônicas, o envio de documentos a serem
anexados a estas publicações, o agendamento e publicação das mesmas no respectivo
Portal onde o órgão realiza as suas negociações eletrônicas. Disponibiliza também a
consulta a ofertas, segundo uma série de filtros de pesquisa (data, situação, itens,
participantes, etc), igualmente para os credenciados na base de dados deste
(fornecedores ou centrais de compras), também segundo diversos filtros (data de
credenciamento, unidade federativa, personalidade, linhas de fornecimento, etc).
2. Utilização
O serviço é disponibilizado às Centrais de Compras, interessadas em integrar os
seus sistemas com o Sistema de Compras Eletrônicas, mediante solicitação. A solicitação
para uso deve ser encaminhada ao administrador responsável pelo portal através do qual
a Central de Compras negocia as suas ofertas de Compra ou Venda por meio eletrônico.
O administrador do portal é responsável por liberar o uso do serviço mediante
tarifação adicional ou não.
2.1. Disponibilidade
Os serviços web estão disponíveis continuamente, da mesma forma que o Sistema
de Compras Eletrônicas, e eventuais períodos de indisponibilidade não programados são
considerados incidentes e serão tratados prioritariamente para reestabelecimento de sua
operação normal o mais breve possível. Qualquer anormalidade na operação dos serviços
web ou do Sistema de Compras Eletrônicas como um todo deve ser reportada
imediatamente, para que o funcionamento normal seja reestabelecido.
Não há limitação de uso dos serviços web além das restrições normalmente
impostas pelo próprio Sistema de Compras Eletrônicas como, por exemplo, tamanho e
formatos válidos de arquivos anexos.
2.2. Responsabilidade
Toda comunicação feita por sistemas externos por meio destes serviços web é
registrada, e na ocorrência de mau uso, atitude suspeita, indevida, ilegal ou inapropriada,
medidas cabíveis serão acionadas.
É de responsabilidade dos sistemas clientes, suas respectivas centrais de compras

e setores de tecnologia da informação, a correta implementação da integração com o

Sistema de Compras Eletrônicas para atendimento de suas necessidades, e a evolução
da respectiva integração conforme evoluírem os serviços web disponibilizados. Da mesma
forma, a central de compras e seus usuários são inteiramente responsáveis pelos dados
transmitidos, assim como por eventuais perdas de prazos, perdas monetárias ou outras
situações adversas em geral, provenientes da publicação de ofertas com datas, valores
ou definições incorretas.
Os serviços web disponibilizados possuem ampla gama de validações e testes
para evitar dados inadequados, os mesmos disponíveis na interface gráfica utilizada para
criação manual de ofertas pelos usuários do sistema, porém certos aspectos da criação
de uma oferta apropriada podem depender de julgamento humano, como a adequação de
valores de referência à realidade do mercado ou a escolha da modalidade de licitação
correta dado o objeto e valores envolvidos, dentre outros tantos. Assim sendo, a
implementação realizada precisa considerar estes aspectos, e resolvê-los da forma
adequada para evitar prejuízo à central de compras.
A título de exemplo, seria recomendável a disponibilização no sistema cliente da
opção para que o usuário deste sistema realize a publicação de uma nova oferta pelo
serviço web de integração em duas etapas: criação com posterior publicação, com opção
de reenvio. A primeira etapa no sistema cliente criaria a oferta na situação “em
composição”, e transferiria os arquivos (anexos vinculados à oferta). Desta forma seria
possível que, uma vez finalizado o envio dos dados, o coordenador responsável por sua
execução acessasse o Sistema de Compras Eletrônicas e revisasse o cadastramento
completo do edital pelas interfaces gráficas deste sistema, podendo sanar erros ou falhas,
e não havendo inconsistências seria executado o agendamento ou publicação através de
uma segunda requisição no sistema cliente. Havendo inconsistências em uma oferta
ainda em composição, cadastrada pelo serviço web de integração, o sistema cliente
deveria disponibilizar a opção para que o usuário pudesse remover a oferta enviada ao
Sistema de Compras Eletrônicas, para correção dos dados no sistema origem, permitindo
o seu reenvio com as correções já aplicadas, garantindo desta forma a integridade dos
dados registrados em ambos sistemas.
3. Características
Os serviços web estão disponíveis através do protocolo SOAP com dados no
formato XML, toda a comunicação executando sobre um canal seguro HTTPS (HTTP
Secure). Não é possível efetuar qualquer comunicação em HTTP simples, nem existem
outros formatos de dados suportados, atualmente. As operações acontecem
sincronamente, retornando o resultado da operação executada ou uma mensagem de
erro, com os detalhes disponíveis sobre a falha ocorrida.
As operações pelo serviço web ocorrem de forma similar às executadas
manualmente pelos usuários do sistema eletrônico. Os mesmos dados informados para
cadastrar uma oferta manualmente serão requeridos na requisição feita pelo serviço web.
Por exemplo, a requisição de criação de uma oferta será recusada se não possuir todos

os dados necessários, que incluem modalidade, descrição de objeto e lotes com seus
respectivos itens e quantidades, e parâmetros pertinentes à disputa. Estes dados
deverão, portanto, ser fornecidos na requisição de forma completa, sendo que o sistema
cliente deverá fornecê-los pela implementação que julgar mais adequada para obtenção
de cada uma das informações, seja por consulta a suas próprias bases de dados,
comunicação com outros sistemas, por inferência baseada em outros dados, por definição
de valores padrão, ou por definição solicitada ao seu usuário.
3.1. Versionamento
Os serviços fornecidos estão em constante evolução e, sempre que necessário,
serão liberadas novas versões dos serviços existentes. Não existe um cronograma
definido ou predeterminado de liberação de novas versões, elas ocorrem de acordo com a
necessidade de evolução do Sistema de Compras Eletrônicas ou do próprio serviço.
Novas versões podem ocorrer para atender alterações legais que impactem a
forma como as operações são executadas, para novas funcionalidades ou modalidades
licitatórias, para evolução técnica, melhoria em procedimentos existentes ou correção de
problemas. Sempre que uma nova versão for liberada, a versão anterior ficará
temporariamente disponível, provavelmente por um período não inferior a três meses,
permitindo que os sistemas clientes se adaptem à nova versão antes de sua
descontinuação.
4. Implementação
A implementação da integração de um sistema cliente com o Sistema de Compras
Eletrônicas é de responsabilidade do órgão ou entidade (central de compras) que deseja
realizar tal integração, com o uso da tecnologia que julgar mais adequada.
Diversos frameworks possuem suporte a implementação do consumo de serviços
web, em diversas linguagens de programação, como Java, C, C++, C#, VB.NET e PHP.
Uma lista de alguns candidatos pode ser encontrada no seguinte endereço:
https://en.wikipedia.org/wiki/List_of_web_service_frameworks
A compreensão das tecnologias envolvidas, como HTTP, SOAP, XML, WSDL e
XSD não fazem parte do escopo deste documento. Tais informações podem ser
encontradas em abundância na Internet, com diversos exemplos de implementação.
4.1. Geração de classes

Em diversas linguagens, tais como Java, C++ e C#, é possível a geração de
classes da linguagem a partir da definição de tipos em XML Schema Definition (XSD)
presente no arquivo WSDL, com o uso de alguma ferramenta específica. Tal geração
automática facilita a geração do XML desejado, preenchendo os objetos e fazendo sua
conversão automática no formato adequado, assim como transformando em objetos
apropriados as respostas ou falhas dos serviços.

Algumas das ferramentas possíveis são:

• Java: JAXB (compilador XJC), em https://jaxb.java.net/
• .NET: XSD Tool, em https://msdn.microsoft.com/en-us/library/x6c1kb0s
%28v=VS.100%29.aspx
• C++: algumas alternativas em http://stackoverflow.com/q/445905/455417
4.2. Autenticação
Para utilização dos serviços web, é necessária a utilização de credenciais
específicas, diferentes das utilizadas por usuários comuns do Sistema. Tais credenciais
serão liberadas pelo administrador responsável. A autenticação é requerida mesmo nas
requisições de consulta.
As credenciais devem ser informadas a cada requisição realizada, no padrão
OASIS Web Service Security, utilizando o UsernameToken Profile 1.0, conforme
exemplificado abaixo:
<soapenv:Header>
<wsse:Security soapenv:mustUnderstand="1"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-
wss-wssecurity-utility-1.0.xsd">
<wsse:UsernameToken wsu:Id="UsernameToken-8B340E62F4652122B5144A6912601331">
<wsse:Username>W123</wsse:Username>
<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-
200401-wss-username-token-profile-1.0#PasswordText">senha</wsse:Password>
<wsse:Nonce
EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-
1.0#Base64Binary">f24aOP2VrSdTyi9PSRGblA==</wsse:Nonce>
<wsu:Created>2015-12-09T16:01:00.132Z</wsu:Created>
</wsse:UsernameToken>
</wsse:Security>
</soapenv:Header>
Para mais informações, leia a documentação do padrão no seguinte endereço:

https://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-
profile-1.0.pdf
4.3. Autenticação descentralizada

Para os sistemas que controlam mais de uma Central de Compras, existe a
possibilidade de autenticar-se em diferentes centrais utilizando o mesmo usuário de
serviço. As credenciais são informadas da mesma forma indicada no item 4.2 deste
manual. A única diferença é a adição de um novo nó chamado “CentralCompras” que
deve conter o código da central pela qual o usuário deseja autenticar-se, conforme
exemplo abaixo:

<soapenv:Header>
<wsse:Security soapenv:mustUnderstand="1"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-
wss-wssecurity-utility-1.0.xsd">
<wsse:UsernameToken wsu:Id="UsernameToken-8B340E62F4652122B5144A6912601331">
<wsse:CentralCompras>1236</wsse:CentralCompras>
<wsse:Username>W123</wsse:Username>
<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-
200401-wss-username-token-profile-1.0#PasswordText">senha</wsse:Password>
<wsse:Nonce
EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-
1.0#Base64Binary">f24aOP2VrSdTyi9PSRGblA==</wsse:Nonce>
<wsu:Created>2015-12-09T16:01:00.132Z</wsu:Created>
</wsse:UsernameToken>
</wsse:Security>
</soapenv:Header>
Para utilizar a autenticação descentralizada é necessário fazer uma solicitação

para o administrador responsável pelo sistema COE. O administrador concederá as
permissões necessárias e fornecerá a lista de códigos de centrais de compras.
4.4. Datas
Um aspecto que merece menção especial são os campos relativos a datas. Tais
campos são informados em formato ISO 8601, e um cuidado especial deve ser dado ao
seu conteúdo, para evitar os conhecidos e populares problemas em relação a fusos
horários e horário de verão.
De forma geral, os campos de data, independente de para qual objetivo foram
enviados ou recebidos, seguem um modelo padrão, descrito a seguir.
4.4.1.Valores recebidos
Datas recebidas do serviço web possuirão o deslocamento (offset) correto de fuso
horário para a referida data de acordo com o horário oficial de Brasília, sendo
deslocamento -03:00 para horário normal e -02:00 para horário de verão.
4.4.2.Valores a enviar
Para enviar datas corretamente ao serviço web, o essencial é que a data recebida
represente o momento correto de acordo com o horário oficial de Brasília definido para o
evento.
As datas devem ser enviadas sem a informação de fuso horário. Isso fará com que
seja assumido o fuso para aquela data segundo a configuração do servidor do serviço
web, que estará configurado corretamente.
Exemplos:
• 2015-06-15T12:30:59+00:00 : equivalente a UTC, adiantado em 3 horas. A

informação de fuso horário será desconsiderada;

Uma data correta para este caso seria, por exemplo:
• 2015-10-17T00:00:00 : fora do horário de verão (implícito -03:00);
• 2015-10-23T12:45:00 : dentro do horário de verão (implícito -02:00);
• 2015-06-15T12:30:59 : fora do horário de verão (implícito -03:00).
4.5. Certificado digital

Até o presente momento, o certificado digital apresentado para as URLs seguras
do Sistema de Compras Eletrônicas é assinado pela ICP-Brasil, e portanto normalmente
não é reconhecido de forma automática como válido por navegadores e outros sistemas
que façam a validação do certificado. Para uma validação correta, será necessária a
importação da cadeia de certificados da ICP-Brasil v2.
Para importação do Certificado da AC Raiz da ICP-Brasil v2, acesse o repositório
do ITI, no seguinte endereço:
http://www.iti.gov.br/icp-brasil/certificados/188-atualizacao/4530-ac-raiz
4.6. Tabelas de conversão

Os dados de unidades de medida e famílias de produtos utlizados neste sistema
são baseados no catálogo da CELIC. Nós disponibilizamos estas tabelas nos links abaixo:
• Unidades de medida: https://www.compras.rs.gov.br/ws/unidades_de_medida.csv

• Famílias: https://www.compras.rs.gov.br/ws/familias.csv
Sempre que este serviço solicitar informações de unidade de medida ou família, ele
estará esperando que este dado seja fornecido com base nas tabelas acima (campo
CODIGO_COE).
4.7. Serviços
Os serviços web disponíveis seguem um padrão comum de definição, e podem ser
utilizados para diferentes propósitos, de forma isolada ou combinada. Vale ressaltar isto:
todas as operações são completamente atômicas, independentes e não transacionais
entre si, de forma que um sistema cliente pode fazer uso de qualquer uma delas, apenas
parte delas ou todas elas da forma que julgar necessário. Por exemplo: ofertas podem ser
criadas e publicadas de forma inteiramente automatizada pelo serviço web, ou
parcialmente criadas a partir do serviço web e publicadas manualmente por um usuário do
Sistema, ou uma oferta criada manualmente por um usuário do Sistema pode ter seus

dados lidos a partir do serviço web. Não há qualquer restrição neste sentido.
Observe que não serão detalhados todos os elementos, campos, valores e
combinações possíveis, visto a grande quantidade de informação, além de que isto é
amplamente fornecido pelo WSDL, em conjunto com a documentação embutida nesta,
criada para complementar informações que não estejam naturalmente clarificadas pelo
XML Schema Definition.
4.7.1.Ofertas
O serviço web de ofertas é o mais extenso e versátil oferecido. Possui a
capacidade da criação completa de uma oferta, anexação de documentos vinculados,
agendamento, publicação, remoção e consulta de ofertas. As operações disponíveis serão
explicadas nesta seção.
Uma oferta pode ser de compra ou venda, para qualquer uma das modalidades
licitatórias, eletrônicas e presenciais, incluindo as dispensas de licitação com e sem
disputa, leilões e o regime diferenciado de contratação (RDC).
O endereço com a definição mais recente do serviço web de ofertas em ambiente
de PRODUÇÃO é o seguinte: versão 3.0
https://www.compras.rs.gov.br/egov2/ws/oferta_3.0.wsdl
4.7.1.1. Criar
Operação principal para a integração entre sistemas cliente e o Sistema de
Compras Eletrônicas, permitindo o envio de grandes massas de dados, liberando o
pregoeiro e outros usuários do longo e altamente propenso a falhas processo de criação
de ofertas para disputa no Sistema. Seu uso permite grande ganho de produtividade,
além da considerável redução da ocorrência de erros humanos.
4.7.1.1.1.Dados
Para seu uso, é necessário que o sistema cliente seja capaz de informar, de uma
única vez, a totalidade dos dados pertinentes à oferta, sendo eles:
• Número e Ano do edital;
• Número, Ano e Tipo do processo administrativo que tenha dado início à licitação.
Este tipo especifica o sistema de origem do processo, que pode ser PROA, SPI,
SEI ou OUTRO;
• Descrição textual do objeto da licitação e definição do tipo de objeto sendo licitado;
• Modalidade licitatória, com todos os detalhes específicos requeridos para a
respectiva modalidade (como forma de execução eletrônica ou presencial,
destinado a registro de preços ou não, etc);
• Todos os lotes que compõem a oferta e seus dados respectivos, sendo eles:

◦ Título e descrição textual resumida do seu objeto;

◦ Dados relevantes à modalidade em questão (como data início, fim e abertura de
propostas, início da sessão de disputa e tempo de duração para os certames
eletrônicos, ou data de realização e local para os certames presenciais, etc);
◦ Dados dos lances a serem enviados (número de casas decimais, unidade
monetária ou percentual, valores crescentes ou decrescentes, restrições de
valores zero e negativo, progresso mínimo dos valores);
◦ Restrições aplicadas aos participantes (preferência baseada no porte,
obrigatoriedade de arquivo anexo, etc);
◦ Tipos de documentos a serem fornecidos pelo melhor classificado do lote na
fase de julgamento de proposta;
◦ Todos os itens que compõem cada lote e seus dados respectivos, sendo eles:
▪ Quantidade e unidade;
▪ Valor de referência;
▪ Embalagem;
▪ Se item pertencente ao Catálogo de Materiais do Estado, seu código;
▪ Se item sob demanda, seu nome, descrição completa e família(s);
▪ Se o tipo de objeto do edital for Obras, deve informar os campos
relacionados ao orçamento-básico do item.
O sistema cliente pode obter essa informação da forma que julgar apropriada,
podendo mesmo ser fruto da união de dados presente em suas bases de dados, dados
padrão, fixos ou inferidos, ou até mesmo perguntados ao usuário. De fato, é bem provável
que parte das informações necessárias não estejam armazenadas no sistema cliente,
possivelmente porque só são relevantes a nível da disputa de um lote, e portanto definir
valores fixos que são corretos para o dado propósito, inferência de valores ou pedir ao
usuário que preencha as informações faltantes são estratégias válidas, senão
necessárias.
4.7.1.1.2.Casos de uso
Disponibilizamos uma documentação complementar contendo XMLs que
demonstram a criação de ofertas em todas as modalidades presentes no COE. Estes
arquivos deverão ser enviados juntamente com este documento. Caso você ainda não
tenha estes exemplos, entre em contato com a equipe do COE.
4.7.1.1.3.Requisição e resposta
O regramento envolvido nos parâmetros a serem informados é extenso e
complexo, além de estar em constante evolução, e não faz parte do escopo desta

documentação. Para sua melhor compreensão, observe a documentação presente em

cada elemento e tipo no XSD, que possuirão um bom detalhamento de sua função e seu
significado; se você utilizar uma ferramenta de conversão de XSD para classes,
possivelmente tais campos de documentação podem passar a fazer parte
automaticamente da documentação de cada classe, campo ou método. E para um
desenvolvimento mais rápido, o envolvimento dos usuários acostumados ao Sistema de
Compras Eletrônicas e a demonstração dos passos necessários à criação de ofertas pode
ser imprescindível. A navegação pela interface de criação de ofertas e análise do valor
adequado a cada campo fornecerá um entendimento mais rápido e direto dos dados que
precisarão ser enviados.
Ao fim de uma requisição bem sucedida, será recebida uma resposta, a qual
possuirá informações importantes:
• Identificador único (ID) da oferta: essencial para os demais passos da composição
de uma oferta, também permite a consulta inequívoca da oferta desejada, quando
consultada por este identificador, portanto este campo deverá ser armazenado pelo
sistema cliente;
• Identificador único (ID) dos lotes da oferta: essencial para a execução de
operações sobre os lotes (ex: homologação, cancelamento). O sistema cliente
deverá armazenar este campo se desejar executar ações em lotes da oferta.
• Códigos de itens sob demanda: para cada item sob demanda (especificado de
forma completa, não pertencendo ao Catálogo do Materiais do Estado) informado,
será retornado o código único deste item gerado no Sistema de Compras
Eletrônicas. Ao armazenar estes códigos juntamente com as respectivas definições
dos itens, é possível ao sistema cliente fazer a reutilização destas definições em
compras futuras (reuso de catálogo próprio), transmitindo menos dados, além de
unificar as informações de todas as compras de um determinado item. Se uma
mesma descrição de um item sob demanda já cadastrado for enviada novamente
ao Sistema, outro registro idêntico de mesmo conteúdo será gerado, com um novo
código; nesta situação, relatórios de uso de um determinado produto (via serviços
web ou pela interface usual do Sistema) serão afetados, pois não será possível
unificar e reportar corretamente as compras do item, associadas a registros com
códigos diferentes porém semanticamente representando o mesmo item.
E adicionalmente, da mesma forma que a repetição do envio da definição de um
item sob demanda gera réplicas da mesma definição, o envio sucessivo de uma definição
de oferta gera duplicatas desta oferta, cada uma com um identificador (ID) distinto.
Campos como número de edital e número de processo não são obrigatoriamente únicos,
e portanto também não impedem tais duplicatas.
A situação da oferta criada ficará “em composição”, dependendo de mais
operações para sua publicação e consequente disponibilização ao grande público.
Uma requisição pode falhar por diversos motivos. Na grande maioria destas, o
sistema cliente receberá uma mensagem de falha da requisição, com o detalhamento

relevante. Para maiores informações, leia a seção 4.8..
4.7.1.1.4.Mutabilidade
Um detalhe importante a mencionar, é que o fato de uma oferta ter sido criada por
uma chamada de serviço web não lhe garante qualquer tratamento especial em relação a
uma oferta criada manualmente por um pregoeiro ou outro usuário. Isso significa dizer
que a oferta gerada poderá ser livremente acessada pelos usuários da central de compras
no Sistema de Compras Eletrônicas e modificada de qualquer forma possível, assim como
outras ofertas na mesma situação.
Cada central de compras que utilizar o serviço pode definir suas formas de
operação, se permitirá que seus usuários revisem as ofertas criadas e façam correções
manualmente, se exigirá remoção, correção de ofertas incorretas e posterior reenvio em
seu próprio sistema cliente para reenvio, ou se proibirá que seus usuários a revisem e
fará a publicação de forma imediata. Todas essas abordagens são válidas, mas não serão
de forma alguma controladas pelo Sistema de Compras Eletrônicas, e portanto deverão
ser gerenciadas pela central de compras e seu sistema da forma que julgarem
conveniente com seus próprios mecanismos ou regramentos de uso e/ou operação.
4.7.1.2. Anexar
A segunda operação obrigatória em uma publicação de oferta é o envio dos
arquivos anexos. Os tipos de documentos obrigatórios para cada oferta são definidos de
acordo com a modalidade e o tipo de objeto.
Modalidade Tipo de objeto Documentos obrigatórios

Todas as modalidades. Bens; Bens e serviços; Serviços; Edital e Anexos
Concessão
Todas as modalidades. Exceto Obras e serviços de engenharia Edital e Anexos; Cronograma;
Dispensas. Detalhamento BDI; Detalhamento
Encargos sociais; Orçamento-
base; Projeto básico/Termo de
referência
4.7.1.2.1.Formato
Sugere-se preferencialmente o uso de um formato aberto padronizado, facilitando
sua leitura pela maior quantidade possível de interessados, neste caso o formato PDF
(Portable Document Format). Formatos proprietários como DOC e XLS possuem
possibilidade de serem ilegíveis a usuários que não possuírem a versão adequada do
software proprietário associado (Microsoft Office), e TXT é um formato muito simples para
documentos complexos como editais.

4.7.1.2.2.Restrições
Documentos anexos enviados estão sujeitos às mesmas limitações de documentos
enviados manualmente, especificamente a restrição de tamanho do arquivo em até 3
megabytes. Para arquivos de até 10 megabytes em uma oferta específica é necessário
fazer uma solicitação para a equipe do Sistema de Compras Eletrônicas, dada justificativa
adequada.
Adicionalmente, o serviço web impõe uma restrição adicional, que é o envio do
arquivo anexo obrigatoriamente com o uso de Message Transmission Optimization
Mechanism (MTOM), uma forma otimizada de enviar dados binários por serviços web.
Consulte a documentação do seu framework de serviços web para maiores informações.
4.7.1.2.3.Anexar documentos após a publicação do edital

É possível enviar documentos após a publicação do edital, porém mais
informações são necessárias. Para fazê-lo é necessário informar o Tipo de publicação
(informação complementar para qualificar o documento), Data de publicação (data em que
o documento foi publicado oficialmente) e o usuário responsável pela publicação do
documento (este usuário deverá ser informado pelo seu CPF (não formatado), o qual
deverá ser um usuário credenciado no Sistema de Compras Eletrônicas com a devida
permissão para executar ofertas na modalidade definida ou ser um homologador da
central, caso contrário resultará em um erro na operação).
4.7.1.3. Publicar
A publicação do edital representa a última fase para a sua disponibilização ao
grande público. Para a publicação, o sistema cliente deverá informar dois dados
importantes:
• A data da publicação da oferta no Diário Oficial, sendo que esta data não possui
restrição, podendo ser no futuro ou no passado:
◦ Se for no passado, a oferta será imediatamente publicada e tornada pública ao
grande público; note que isto significa que ao menos algum tempo (minutos,
horas, possivelmente dias ou muito mais) se passaram desde que a oferta
deveria supostamente estar disponível publicamente, e se isto resultar em
redução do tempo em que participantes possuem para enviar seus lances para
participação, poderão haver medidas legais tomadas por tais usuários;
◦ Se for no futuro, a oferta permanecerá em composição e será automaticamente
publicada ao chegar nesta data, à meia-noite; esta é a forma preferencial de
publicar ofertas (na verdade um agendamento de publicação), garantindo
igualdade de oportunidade aos participantes e redução da possibilidade de
qualquer ação legal contra a oferta publicada fora do prazo legal (em
desconformidade com a publicidade legal requerida para a modalidade);
• O usuário responsável pela publicação da oferta no portal: este usuário será

associado à oferta e seu nome e contato constarão publicamente na oferta como o

responsável por pedidos de esclarecimento e impugnações; este usuário deverá
ser informado pelo seu CPF (não formatado), o qual deverá ser um usuário
credenciado no Sistema de Compras Eletrônicas com a devida permissão para
publicar ofertas na modalidade definida na oferta, caso contrário resultando em um
erro na operação;
• O número, ano e tipo da comissão de licitação deste edital (obrigatório para todas
as modalidades, exceto para Dispensas). Esta comissão de licitação deve estar
previamente cadastrada no COE.
4.7.1.4. Remover
A operação de remoção é uma conveniência para processos mais automatizados
de interação com o Sistema de Compras Eletrônicas.
No caso de uma oferta ser criada no Sistema e antes de sua publicação uma falha
em sua criação ser observada, é possível então remover completamente a primeira oferta,
ajustá-la no sistema cliente, e então enviar novamente a definição completa, minimizando
a ocorrência de ajustes manuais pelos usuários através do Sistema de Compras
Eletrônicas.
Note, contudo, que a remoção de uma oferta remove qualquer informação relativa
a tal oferta, fazendo seu número de identificação (ID) permanentemente inválido, e a nova
oferta receberá outro ID. Adicionalmente, qualquer item sob demanda criado para esta
oferta e que não tenha ainda sido reutilizado para outra oferta será igualmente removido,
portanto um reenvio da oferta corrigida não poderá utilizar os códigos de item recebidos
na primeira criação da oferta e precisará enviar novamente a definição completa de cada
um dos itens removidos.
Para facilitar o controle de quais itens sob demanda ainda são válidos (isto é,
utilizados em outras ofertas) no Sistema de Compras Eletrônicas, a execução da
operação de remoção retorna a lista de todos os itens sob demanda removidos
juntamente com a oferta em questão. O sistema cliente deverá processar essa resposta,
registrando em seu catálogo quais itens foram excluídos do Sistema de Compras
Eletrônicas para que seus códigos respectivos não sejam reutilizados, e que os
respectivos itens sejam novamente tratados como itens sob demanda com especificação
completa em uma nova oferta. Em outras palavras, o sistema cliente deverá apagar a
referência que possuía ao código do item no Sistema de Compras Eletrônicas. Esse
controle é de responsabilidade do sistema cliente, e sua correta implementação é
importante para garantir o máximo reuso das definições de itens sob demanda e a
minimização da ocorrência de falhas por uso de códigos de item inválidos por remoção de
ofertas.
Como uma observação adicional, a realização da remoção de uma oferta de forma
manual por um usuário do Sistema de Compras Eletrônicas, como um pregoeiro, excluirá
itens sob demanda da mesma forma como descrito acima, porém a informação de quais

itens sob demanda foram excluídos será perdida, de forma que o sistema cliente não
estará ciente da invalidade dos respectivos itens, e ocasionará erros na ocorrência do
reuso de tais códigos de item. Desta forma, sugere-se fortemente que, se a central de
compras responsável pelo sistema cliente realiza remoção de ofertas para retificações
nos dados enviados, esta operação seja implementada na integração entre os sistemas e
a exclusão manual seja desaconselhada, para minimização dos problemas descritos
acima.
4.7.1.5. Consultar
Trata-se da mais complexa e flexível das operações disponíveis, e requer uma
explicação mais detalhada.
Esta consulta foi criada de forma versátil, permitindo a consulta de diversas
informações relativas a uma ou mais ofertas, dando ao sistema cliente a possibilidade de
buscar apenas os dados necessários para seus objetivos, também abrindo a possibilidade
de integrações mais complexas sem a necessidade de um novo serviço web para tal.
De forma mais objetiva, esta operação permite o uso de diversos filtros de forma
altamente independente, sob diversos aspectos de uma oferta, lote, itens ou seus
proponentes, também fazendo a busca apenas dos dados desejados e ignorando outros,
de forma a reduzir a transmissão de informações irrelevantes para o propósito da
consulta.
Para referência pelo resto desta seção, o formato de uma consulta é o seguinte:
<consultarRequisicao inicio="?" quantidade="?" escopo="?">

<oferta detalhes="?">
<identificacao>
<id>?</id>
<edital>?</edital>
<processo>?</processo>
</identificacao>
<modalidade tipo="?">
<presencial>?</presencial>
<registroPreco>?</registroPreco>
<dataRealizacao>?</dataRealizacao>
<sessaoDisputa>?</sessaoDisputa>
<fundamentoLegal>?</fundamentoLegal>
<credenciamento>?</credenciamento>
<modoDisputa>?</modoDisputa>
<criterioJulgamento>?</criterioJulgamento>
</modalidade>
<situacao tipo="?"/>
<periodo tipo="?">
<de>?</de>
<ate>?</ate>
</periodo>
<lote detalhes="?" homologado=”?”>
<id>?<id/>
<situacao tipo="?"/>
<periodo tipo="?">
<de>?</de>
<ate>?</ate>
</periodo>
<item detalhes="?">

<identificacao>
<codigo>?</codigo>
<familia>?</familia>
</identificacao>
</item>
<proponente detalhes="?">
<identificacao>
<id>?</id>
<registro tipo="?">?</registro>
</identificacao>
<classificacao vencedor="?"/>
<proposta detalhes="?"/>
</proponente>
</lote>
</oferta>
</consultarRequisicao>
4.7.1.5.1.Filtros
Atualmente, os filtros possíveis são:
• Ofertas:
◦ Identificação (ID, número de edital e/ou número de processo administrativo);
◦ Modalidade (tipo, forma de execução presencial ou eletrônica, destinadas para
registro de preço ou não, e todos os demais campos de definição de
modalidade);
◦ Situação (em composição, em andamento, homologada, cancelada ou deserta);
◦ Período (datas de publicação, alteração e finalização);
◦ Para cada um dos seus lotes:
▪ ID do lote;
▪ Situação (em andamento, adjudicado, não adjudicado, cancelado ou
deserto);
▪ Homologação (lotes homologados ou não homologados);
▪ Período (datas de início, alteração e finalização);
▪ Para cada um dos seus itens:
• Identificação (código e/ou família de fornecimento);
▪ para cada um dos seus proponentes:
• Identificação (ID e/ou número de registro, tal como CPF ou CNPJ);
• Classificação (apenas vencedor ou não).
Todos estes filtros podem ser especificados em qualquer combinação possível.
Filtros distintos, com nomes de elemento diferentes entre si, operam como conjunções
lógicas (“AND”), enquanto filtros que se repetem operam como disjunções lógicas entre si

(“OR”). Em outras palavras ao definir um filtro de “situação” e um de “período”, os

resultados retornados estarão simultaneamente atendendo à situação e ao período. Por
exemplo:
<oferta>
<situacao tipo="HOMOLOGADA"/>
<periodo tipo="ALTERACAO">
<de>2014-10-17T00:00:00</de>
<ate>2014-10-23T12:45:00</ate>
</periodo>
</oferta>
Todos os registros retornados retornados com o uso desse filtro serão ofertas
atualmente homologadas e que tenham sido alteradas entre a meia-noite de 17 de
outubro de 2014, incluso, e 23 de outubro de 2014 às 12:45, excluso (isto é, até o último
instante antes das 12:45 de 23 de outubro de 2014 – mais informações a seguir).
Outro exemplo:
<oferta>
<identificacao>
<id>202799</id>
</identificacao>
<identificacao>
<edital>PE 001/2015</edital>
<processo>085771-20.00/15-6</processo>
</identificacao>
<identificacao>
<processo>004084-04.35/15-0</processo>
</identificacao>
<situacao tipo="CANCELADA"/>
<situacao tipo="DESERTA"/>
</oferta>
Os registros retornados com este filtro serão as ofertas com ID 202799, ou com
número de edital “PE 001/2015” e número de processo “085771-20.00/15-6”, ou com
número de processo “004084-04.35/15-0”, e cada uma delas precisará estar atualmente
finalizada, ou seja, homologada, cancelada ou deserta.
Filtros podem ser combinados entre diversos níveis de granularidade, como sob
campos de oferta e de lote, por exemplo. Para que um registro seja retornado, ele precisa
atender simultaneamente a todos os filtros em todos os níveis. Exemplo:
<oferta>
<lote>
<situacao tipo="ADJUDICADO"/>
<situacao tipo="NAO_ADJUDICADO"/>
</lote>
</oferta>

Para este filtro, serão retornadas todas as ofertas que estiverem homologadas e
que possuam lotes que estejam adjudicados ou não adjudicados. Se uma oferta
homologada possuir lotes adjudicados e lotes cancelados, só serão retornados os lotes
adjudicados. Se uma oferta homologada possuir lotes cancelados e desertos, esta oferta
não será retornada, e consequentemente nenhum de seus lotes.
Adicionalmente, os filtros de período possuem alguns detalhes de comportamento
que necessitam de clarificações adicionais:
• Todo período especificado precisa de uma data de partida (elemento <de/> ), mas
não necessita de uma data limite (elemento <ate/> ), neste caso representando
períodos até o momento da consulta;
• Datas de partida são instantes inclusos, significando que aquele instante específico
está incluído nos resultados da pesquisa, porém a data limite é exclusa, o que
significa que serão retornados registros que atendam ao período desejado até o
último instante anterior ao especificado, mas não o próprio. A consequência disso é
que para especificar uma pesquisa que inclua todo o ano de 2015, a seguinte
consulta é incorreta:
<oferta>
<periodo tipo="PUBLICACAO">
<de>2015-01-01T00:00:00</de>
<ate>2015-12-31T23:59:59</ate>
</periodo>
</oferta>
O correto para esta pesquisa seria:
<oferta>
<de>2015-01-01T00:00:00</de>
<ate>2016-01-01T00:00:00</ate>
</periodo>
</oferta>
• Ao contrário do exposto anteriormente, múltiplos filtros de período em um mesmo

elemento não representam uma disjunção lógica e sim uma conjunção, pois por
mais que estejam definidos pelo mesmo elemento <periodo/> , operam sobre
conjuntos de datas diferentes. Exemplificando:
<oferta>
<de>2014-01-01T00:00:00</de>
<ate>2014-02-01T00:00:00</ate>
</periodo>
<periodo tipo="FINALIZACAO">
<de>2014-06-01T00:00:00</de>
<ate>2014-07-01T00:00:00</ate>
</periodo>
</oferta>
Neste caso, estariam sendo procurados todas as ofertas publicadas em janeiro de
2014 e finalizadas em julho de 2014. Uma oferta publicada em janeiro de 2014 e
não finalizada durante o mês de julho de 2014 não será retornada pela consulta.
• Estão presentes na oferta e no lote a filtragem período de finalização. Esta não é
uma situação “nominal” que possa ser encontrada, mas representa a união de

todas as situações finais que uma oferta (homologada, deserta ou cancelada) ou

lote (adjudicado, não adjudicado, deserto, cancelado) possa atingir, permitindo
desta forma a consulta pela data em que uma oferta e/ou lote foi finalizado,
independente de qual situação foi atingida.
Como foi possível demonstrar, o uso dos filtros é extremamente flexível e capaz de
diversas buscas interessantes, contanto que seja corretamente aplicado. Sugere-se que
seja experimentada a operação de consulta em ambiente de homologação para melhor
compreensão das combinações possíveis.
4.7.1.5.2.Limitações e particularidades
Existem certas limitações impostas ao uso desta consulta, e é importante estar
ciente de quais são elas.
Primeiramente, existe a limitação do escopo da busca. Este parâmetro está
definido no elemento de requisição da consulta, e mais frequentemente receberá o valor
“próprio”, significando que só serão consultadas ofertas da própria central de compras a
qual está fazendo a requisição. O escopo “hierarquia” ainda não está disponível para uso,
enquanto os demais são para uso exclusivo das centrais de alto nível (Central de
Licitações do Estado do RS – CELIC – e Banrisul).
Em segundo lugar, há um filtro implícito e permanente sobre a data de publicação
de uma oferta: nenhuma oferta com data de publicação anterior a 1º de janeiro de 2014
será retornada, em qualquer hipótese. Essa limitação é independentemente do uso ou
não do filtro de um período de publicação, e ela existe para garantir uniformidade nos
dados consultados, tendo em vista diferenças nos formatos existentes antes desta data.
Ofertas publicadas anteriormente a essa data terão a aparência de não existir, quando
consultadas pelo serviço web, porém continuará normalmente disponível para consulta
pelos usuários pelo portal web e pelo Sistema de Compras Eletrônicas.
Outra limitação é que, para evitar que uma massa de dados excessivamente
grande seja requisitada, processada e ordenada, é obrigatório a qualquer consulta que
uma das seguintes condições seja atendida:
• Utilizar um filtro de identificação de oferta (ID, número de edital ou número de
processo administrativo);
• Utilizar um filtro de período de oferta com duração máxima de 12 meses;
• Utilizar um filtro de período de lote com duração máxima de 12 meses.
Ao atender qualquer um destes critérios, os demais filtros poderão ser definidos de
qualquer forma desejada, incluindo períodos superiores a 12 meses.
E como última limitação, dados de ofertas “em composição” não são acessíveis
pelo serviço web, se restringindo tão somente aos seus campos de identificação. Como
consequência, não é possível pesquisar e obter dados de ofertas em composição ao usar
qualquer filtro exceto de identificação da oferta. Ou seja, ofertas em composição só

podem ser acessadas de forma “nominal”.

Observe também que não há qualquer limitação à combinação ilógica de filtros, de
forma a impossibilitar a ocorrência de registros, e em tais situações nenhum registro será
retornado. Exemplo de tais combinações:
• Período qualquer anterior ao de publicação;
• Período qualquer posterior ao de finalização;
• Oferta em situação cancelada/deserta, e que tenham lotes em situação diferente
de cancelado/deserto.
4.7.1.5.3.Elementos
O controle de quais elementos devem ser retornados ou não em uma resposta é
definido pela presença de tais elementos no XML da requisição. Isto significa que se você
incluir o elemento “lote” na sua requisição, os lotes de uma oferta serão retornados na
resposta a esta chamada, e se você não incluir este elemento, tal informação será
omitida. Por exemplo:
<oferta>
<de>2015-01-01T00:00:00</de>
<ate>2016-01-01T00:00:00</ate>
</periodo>
<lote>
</lote>
</oferta>
Esta requisição retornará todas as ofertas e seus respectivos lotes que atenderem
ao filtro especificado (em cinza, pois não é o foco desta seção), porém não serão
retornadas informações dos itens dos lotes, os proponentes de cada lote nem suas
respectivas propostas.
Veja este outro exemplo:
<oferta>
<de>2015-01-01T00:00:00</de>
<ate>2016-01-01T00:00:00</ate>
</periodo>
<lote>
<proponente>
<proposta/>
</proponente>
</lote>
</oferta>

Para esta requisição, serão retornadas as ofertas, seus lotes, os proponentes de

cada um e suas respectivas propostas, enquanto a informação dos itens de cada lote não
estará presente.
Considerando esta definição e o uso de filtros, fica implícito que o uso de um filtro
forçará a presença do elemento sobre o qual ele se define, e um elemento não precisa
possuir filtros para estar presente (neste caso, sempre estará presente).
O uso deste recurso é extremamente importante para o controle do tamanho da
resposta gerada para as consultas. A eliminação de elementos não necessários permite
consultas mais rápidas e respostas mais curtas, reduzindo ainda mais o tempo de
resposta e o tempo que o usuário final espera por uma operação.
4.7.1.5.4.Detalhamento
Além da correta definição dos elementos desejados, conforme explicado no item
anterior, outra forma de controlar quanta informação é desejada é através dos atributos de
“detalhes”.
Todos os elementos relacionados à estrutura da resposta (oferta, lote, item,
proponente e proposta) possuem um atributo denominado “detalhes”, de valor booleano
com valor padrão “false”, e que podem ser definidos de forma independente entre si,
conforme desejado. Estes atributos controlam quantos detalhes do seu respectivo
elemento serão retornados, se de forma resumida ou detalhada (completa). Para cada
elemento, estas informações são:
• Oferta:
◦ Resumida: ID, ID da central de compras que publicou a oferta, número de
edital, número de processo administrativo e tipo de situação;
◦ Detalhada: objeto, modalidade, local, grupos de notificação, e
responsável/data/descrição da situação;
• Lote:
◦ Resumido: ID, número de sequência e tipo de situação;
◦ Detalhado: título, descrição, informações de agendamento, informações de
lances, informações de homologação, restrições, tipos de documento de
julgamento de proposta, e responsável/data/descrição da situação;
• Item:
◦ Resumido: número de sequência e código;
◦ Detalhado: nome, descrição, famílias associadas, quantidade, unidade de
medida, valor de referência, embalagem e todos os campos referentes ao
orçamento-base (tipo orçamento, fonte referência, etc)

• Proponente:
◦ Resumido: ID, número de registro principal (CNPJ ou CPF), tipo de situação;
◦ Detalhado: razão social (PJ) ou nome (PF) e declaração de porte;
• Proposta:
◦ Resumida: valor da proposta final;
◦ Detalhada: proposta inicial (valor total, valor por item e marca/modelo de cada
item) e valor final por item.
4.7.1.5.5.Resposta
A resposta recebida respeitará os filtros requisitados e o grau de detalhamento
especificado, conforme detalhado nos itens anteriores. O ordenamento será sempre em
ordem crescente de ID de oferta.
Observe quem nem todas as informações estarão disponíveis em todos os casos,
pois dependem de quais informações foram informadas ao Sistema de Compras
Eletrônicas e da situação atual ou de término de cada oferta ou lote, podendo afetar a
disponibilidade de informações. Alguns exemplos de limitação de informações são:
• Ofertas em composição nunca retornam informação alguma além de dos dados
resumidos de oferta;
• Lotes que não tiveram suas propostas abertas pelo coordenador da disputa nunca
retornam informações sobre os proponentes e propostas registradas, mesmo que
em situação encerrada (ou seja, um lote cancelado só exibirá as ofertas enviadas
para ele se as propostas tiverem sido abertas antes do cancelamento do lote);
• Marca e modelo de itens podem não ter sido especificados por todos os
participantes para todos os itens ou parte deles;
• Detalhamento de valor por item na proposta final só está disponível para o
vencedor do respectivo lote (não sendo um lote adjudicado, essa informação só
estará disponível se foi informada antes da finalização do lote, ou seja, do seu
cancelamento ou não adjudicação).
4.7.1.5.6.Paginação
Um recurso importante para as consultas é a possibilidade (ou necessidade) de
paginação dos resultados. Ela é controlada pelos atributos “início” e “quantidade”
presentes no elemento de requisição da consulta. Como já provavelmente esperado, eles
representam, respectivamente, o primeiro registro a ser retornado pela consulta
(começando em zero), e quantidade máxima de registros a serem retornados na consulta.
Em caso de serem encontrados mais registros do que possíveis para uma única resposta,
o sistema cliente, fica com a responsabilidade de repetir a consulta com os mesmos filtros
utilizados, porém atualizando estes parâmetros de forma sucessiva, até ler todos os

registros desejados.
Contudo, há uma particularidade de comportamento em relação à paginação. Isso
se deve ao fato de uma consulta poder retornar menos registros do que a quantidade
solicitada, por mais que ainda existam registros além de tal quantidade. Tal fato ocorre
pois o sistema julga a quantidade de dados a ser retornada e também o grau de
detalhamento solicitado para cada elemento, e se por acaso julgar que a massa de dados
a ser retornada é muito grande, ele poderá retornar menos registros, e o sistema cliente
deverá igualmente repetir suas consultas até obter todos os dados desejados.
Exemplificando, o sistema cliente faz a seguinte requisição:
<consultarRequisicao inicio="0" quantidade="10000" escopo="PROPRIO">

<oferta detalhes="true">
<de>2014-01-01T00:00:00</de>
<ate>2015-01-01T00:00:00</ate>
</periodo>
<lote detalhes="true">
<item detalhes="true"/>
<proponente detalhes="true">
<proposta detalhes="true"/>
</proponente>
</lote>
</oferta>
O Sistema de Compras Eletrônicas faz a consulta e encontra um total de 3.673

ofertas publicadas pela central de compras em 2014. Contudo, já que foi requisitado o
máximo grau de detalhamento de todas as ofertas, o sistema julgou que retornar apenas
1.145 seria adequado para evitar uma resposta grande demais. Neste momento, a
seguinte resposta seria enviada:
<consultarResposta dataHora="2015-12-10T17:12:55-02:00" inicio="0" quantidade="1145"

total="3673">
<oferta id="123" publicador="999">
...
</oferta>
...
</consultarResposta>
Observe que o campo “início” será retornado com o mesmo valor fornecido da
requisição, enquanto “quantidade” será a quantidade de ofertas efetivamente retornadas e
“total” será o valor total de ofertas encontradas para este filtro. Neste momento o sistema
cliente estaria encarregado de fazer uma nova requisição com os mesmos filtros, porém
com o campo “início” (e “quantidade”, se desejado). Exemplo:

<de>2014-01-01T00:00:00</de>

<ate>2015-01-01T00:00:00</ate>
</periodo>
</proponente>
</lote>
</oferta>
O Sistema de Compras Eletrônicas repetirá a busca e encontrará (possivelmente)

os mesmos resultados, desta vez retornando a partir do 1.146º registro em diante,
digamos retornando mais 1.206 registros, e portanto enviando a seguinte resposta:
<consultarResposta dataHora="2015-12-10T17:12:57-02:00" inicio="1145" quantidade="1206"

total="3673">
<oferta id="5678" publicador="999">
...
</oferta>
...
</consultarResposta>
O sistema cliente deverá então somar 1.145 a 1.206, chegando a 2.351, o que
significa que ainda existem registros a consultar, e deverá repetir o processo até ler todos
os registros desejados.
Expandindo o exemplo, observe que se então o sistema cliente resolvesse reduzir
a quantidade de dados desejados a partir de uma modificação no filtro, possivelmente
mais registros poderiam ser retornados de uma vez:

<oferta>
<de>2014-01-01T00:00:00</de>
<ate>2015-01-01T00:00:00</ate>
</periodo>
<lote>
</proponente>
</lote>
</oferta>
Nesta nova situação, tendo aberto mão dos detalhes das oferta e dos lotes, assim
como de qualquer informação sobre os itens dos lotes, o Sistema de Compras Eletrônicas
poderia passar a julgar que das 3.673 ofertas encontradas, 2.833 podem ser retornadas
de uma única vez, reduzindo o número de consultas necessárias para ler toda a
informação.
Vale ressaltar que o valor “quantidade” informado em uma requisição jamais será
ultrapassado, portando um sistema cliente pode escolher receber os dados em conjuntos

menores, se assim desejar. Adicionalmente, o cálculo feito por trás da escolha da

quantidade de registros a retornar pode sofrer ajustes e melhorias ao longo da evolução
do Sistema, e nenhum sistema cliente deverá basear seu funcionamento na quantidade
de registros que outrora recebia, devendo sempre avaliar a situação presente em cada
requisição.
Para facilitar um pouco a absorção das informações, aqui estão exemplificados
alguns casos de uso possíveis para requisições de consulta à ofertas.
• Retorno de todas as informações de uma oferta com ID 1234 assim que esta for
finalizada no sistema:
<identificacao>
<id>1234</id>
</identificacao>
</proponente>
</lote>
</oferta>
• Uma consulta resumida da anterior, sem detalhes de oferta ou lote nem
informações de item, e retornando apenas as informações do proponente que
venceu a disputa:
<oferta>
<identificacao>
<id>1234</id>
</identificacao>
<lote>
<classificacao vencedor="true"/>
</proponente>
</lote>
</oferta>
• Pesquisa de preços pagos por um item com código 123123 no segundo semestre
de 2014, considerando valores de lotes adjudicados neste período, mas não
necessariamente de ofertas homologada; observe que neste caso apenas o
detalhamento de proposta foi requisitado, pois todos os outros dados seriam
irrelevantes:
<oferta>

<lote>
<de>2014-07-01T00:00:00</de>
<ate>2015-01-01T00:00:00</ate>
</periodo>
<item>
<identificacao>
<codigo>123123</codigo>
</identificacao>
</item>
<proponente>
</proponente>
</lote>
</oferta>
• Idêntico ao exemplo anterior, porém restringindo a lotes que foram efetivamente
liberados para contratação (ou seja, apenas em ofertas homologadas):
<oferta>
<lote>
<de>2014-07-01T00:00:00</de>
<ate>2015-01-01T00:00:00</ate>
</periodo>
<item>
<identificacao>
<codigo>123123</codigo>
</identificacao>
</item>
<proponente>
</proponente>
</lote>
</oferta>
• Pesquisa de ofertas publicadas no início de 2014 e que ainda não foram finalizadas
(para indicar processos que potencialmente já foram homologados no papel, mas
ainda não no Sistema de Compras Eletrônicas, afetando a publicidade dos atos
administrativos):
<oferta>
<situacao tipo="EM_ANDAMENTO"/>
<de>2014-01-01T00:00:00</de>
<ate>2014-03-01T00:00:00</ate>
</periodo>
</oferta>
• Pesquisa por lotes homologados de uma oferta específica. Ao especificar o atributo
homologado no nó lote, serão retornados os lotes homologados (true) ou não
homologados (false). Caso o atributo não seja especificado, este filtro não será
aplicado.
<oferta detalhes="false">
<identificacao>
<id>13734</id>

</identificacao>
<lote detalhes="true" homologado="true"></lote>
</oferta>
4.7.1.6. Cancelar
Atenção: esta ação é executada sobre os lotes de uma oferta.
A ação Cancelar, assim como a Homologar são as únicas duas operações que
finalizam a execução processual de um lote no Sistema de Compras Eletrônicas. O
cancelamento é utilizado para anular em caso de vícios ou ilegalidades encontrados na
fase interna e/ou externa do processo licitatório ou em casos de revogação por interesse
público. Esta ação deve ser executada, obrigatoriamente, por um homologador(a) da
central de compras.
4.7.1.6.1.Dados
Esta ação espera um lote ou uma lista de lotes contendo as seguintes informações:
• Identificador único (ID) do lote: este identificador é retornado no momento da
criação da oferta, mas pode ser encontrado também na consulta de ofertas;
• Usuário: usuário responsável pelo cancelamento do lote. Este usuário deverá ser
informado pelo seu CPF (não formatado), o qual deverá ser um usuário
credenciado no Sistema de Compras Eletrônicas e homologador da central, caso
contrário resultará em um erro na operação;
• Justificativa: justificativa textual do cancelamento e o tipo de cancelamento. O tipo
de cancelamento pode ser uma Anulação de Ofício, Anulação por determinação
judicial ou Revogação de ofício.
4.7.1.6.2.Restrição
A operação só será efetivada se todos os lotes requisitados forem cancelados
devidamente. Se ao menos um lote falhar, toda a operação será desfeita.
4.7.1.6.3.Resposta
Em caso de sucesso, será retornado uma lista com os identificadores dos lotes
cancelados.
4.7.1.7. Homologar
A ação Homologar é responsável por finalizar a execução processual de um lote no
Sistema de Compras Eletrônicas. Esta ação deve ser executada, obrigatoriamente, por
um homologador(a) da central de compras.

4.7.1.7.1.Dados
A homologação espera um lote ou uma lista de lotes contendo as seguintes
informações:
• Usuário: usuário responsável pela homologação do lote. Este usuário deverá ser
contrário resultará em um erro na operação;
• Data: data do registro de homologação. Esta data deve ser anterior ou igual à data
atual.
A operação só será efetivada se todos os lotes requisitados forem homologados
devidamente. Se ao menos um lote falhar, toda a operação será desfeita.
Somente lotes na situação Adjudicado, Não-adjudicado e Deserto podem ser
homologados.
4.7.1.7.3.Resposta
Em caso de sucesso, será retornado uma lista com os identificadores dos lotes
homologados.
4.7.1.8. Desfazer fase

A ação Desfazer fase deve ser utilizada somente em situações excepcionais, pois
ela desfaz uma fase inteira executada no processo licitatório. Para desfazer uma fase é
necessário possuir justificativa legal. Além disso, a responsabilidade de avaliar a
necessidade de republicação no Diário Oficial é da própria central de compras.
4.7.1.8.1.Dados
Para desfazer fase é necessário um lote ou uma lista de lotes contendo as
seguintes informações:
• Usuário: usuário responsável pela ação desfazer fase. Este usuário deverá ser
contrário resultará em um erro na operação.

• Justificativa: justificativa textual para a execução da ação desfazer fase.
Através deste WebService só é possível desfazer as fases: Adjudicação, Não-
adjudicação, Cancelamento e Homologação.
A operação Desfazer fase só será efetivada se todos os lotes requisitados
obtiverem sucesso. Se ao menos um lote falhar, toda a operação será cancelada.
4.7.1.8.3.Resposta
Em caso de sucesso, será retornado uma lista com o identificador (ID), situação
atual e indicador de homologação dos lotes em que a fase foi desfeita.
4.7.2.Credenciados
O serviço web de credenciados permite a consulta, novamente fornecida de uma
forma versátil, de diversas informações relativas a um ou mais credenciados na base de
dados do sistema de Compras Eletrônicas. Além disso, é possível administrar o cadastro
de fornecedores, porém esta funcionalidade só é disponibilizada para usuários de
integração com permissão específica para esta ação.
O endereço com a definição mais recente do serviço web de credenciado em
ambiente de PRODUÇÃO é o seguinte: versão 1.0
https://www.compras.rs.gov.br/egov2/ws/credenciado_1.0.wsdl
4.7.2.1. Consultar
Dada a extensa explicação fornecida para a consulta de ofertas na seção 4.7.1.5. e
o fato de a maior parte se aplicar da mesma forma a esta consulta, esta seção será mais
resumida.
Para referência pelo resto desta seção, o formato de uma consulta é o seguinte:
<consultarRequisicao inicio="?" quantidade="?" credenciamento="?">

<credenciado detalhes="?">
<identificacao>
<id>?</id>
<registro tipo="?">?</registro>
</identificacao>
<registro tipo="?"/>
<periodo tipo="?">
<de>?</de>
<ate>?</ate>
</periodo>
<credenciador id="?"/>
<autorizacaoCredenciamento>?</autorizacaoCredenciamento>
<linhaFornecimento>?</linhaFornecimento>
<contato detalhes="?">
<endereco detalhes="?">
<uf>?</uf>
</endereco>

<responsavel detalhes="?"/>
</contato>
</credenciado>
4.7.2.1.1.Filtros
Atualmente, os filtros possíveis são:
• Credenciados:
◦ Identificação (ID, número de registro);
◦ Existência de número de registro;
◦ Período (datas de criação, renovação ou alteração);
◦ ID de credenciador;
◦ Situação;
◦ Autorização de credenciamento;
◦ Linhas de fornecimento;
◦ Dados de contato:
▪ Unidade da Federação.
O funcionamento dos filtros e a flexibilidade de consultas são similares ao
disponível para consulta de ofertas, descritos na seção 4.7.1.5.1.. Para maiores
informações, leia a seção mencionada.
4.7.2.1.2.Limitações e particularidades
Assim como para a consulta de ofertas, há algumas limitações existentes neste
serviço, e aqui elas serão relatadas.
A primeira é, da mesma forma, a existência de um escopo de busca, aqui
determinado “credenciamento”, pois refere-se ao tipo de credenciamento a ser
consultado. Os tipos possíveis são “central de compras” (órgão ou entidade pública que
publica as suas ofertas de compra ou venda no portal) ou “fornecedor” (tipo que agrupa
também os credenciados como compradores para os leilões e concessões de uso de
bens e serviços públicos). Assim sendo, você apenas poderá buscar um dos dois tipos em
cada requisição realizada.
A segunda limitação é que buscas feitas por credenciados sem o uso de um campo
de identificação (ID ou número de registro) só busca por credenciamentos atualmente
ativos no Sistema, isto é, autorizados a utilizar o Sistema de Compras Eletrônicas no atual
momento. Credenciados inativos podem ser pesquisados apenas com o uso de algum de
seus campos de identificação. Com isto, mesmo que seja necessário pesquisar as
informações de um fornecedor que venceu uma licitação no passado mas desde então foi
descredenciado por qualquer motivo, seus dados ainda estarão acessíveis, porém não

serão visíveis em uma busca mais ampla e não direcionada, por período de solicitação
(criação) ou de credenciamento.
E mais uma vez similarmente ao serviço de ofertas, um filtro mínimo deve ser
fornecido para que não seja processado um conjunto grande demais de empresas. O filtro
utilizado deverá, portanto, atender a pelo menos uma das seguintes condições:
• Utilizar um filtro de identificação de credenciado;
• utilizar um filtro de período de credenciado com duração máxima de 12 meses
(restrição exclusiva para pesquisa de fornecedores).
E para finalizar, há alguns filtros e elementos exclusivos a um ou outro tipo de
credenciado escolhido:
• Filtro de autorização de credenciamento é exclusivo para centrais de compras;
• Filtro de linhas de fornecimento e informações de responsável são exclusivos para
fornecedores.
4.7.2.1.3.Elementos
O controle de quais elementos devem ser retornados ou não em uma resposta é
definido pela presença de tais elementos no XML da requisição, da mesma forma que
exposto na seção 4.7.1.5.3., e portanto não será novamente exposto.
4.7.2.1.4.Detalhamento
Os atributos de “detalhes” novamente funcionam de forma similar ao exposto na
seção 4.7.1.5.4. sobre consulta de ofertas. Para cada elemento, as informações
retornadas para o modo resumido e detalhado são:
• Credenciado:
◦ Resumido: ID, ID do credenciador, um número de registro (CNPJ ou CPF),
situação, e razão social (PJ) ou nome (PF);
◦ Detalhado: demais números de registro, nome fantasia, portal associado
(apenas para centrais de compras), porte (se disponível no Cadastro de
Fornecedores do Estado), datas de criação, atualização e última renovação;
• Contato:
◦ Resumido: nenhuma informação;
◦ Detalhado: telefone e fax;
• Endereço:
◦ Resumido: cidade e unidade da federação;
◦ Detalhado: logradouro, número, complemento, CEP e código do município
(IBGE);
• Responsável:

◦ Resumido: nome;
◦ Detalhado: e-mail, com nível de preferência de notificação definido pelo usuário
e situação do endereço de e-mail registrado no seu cadastro (verificado ou
não).
4.7.2.1.5.Resposta
A resposta recebida respeitará os filtros requisitados e o grau de detalhamento
especificado, conforme detalhado nos itens anteriores, e as limitações já expostas. O
ordenamento será sempre em ordem crescente de ID de credenciado.
4.7.2.1.6.Paginação
A paginação dos resultados ocorre da mesma forma exposta na seção 4.7.1.5.6.
sobre ofertas, e não será repetida.
E a seguir, alguns exemplos de possibilidades de uso para o serviço:
• Retorno de todas as informações de três empresas fornecedoras, identificadas por
ID e CNPJ:
<consultarRequisicao inicio="0" quantidade="3" credenciamento="FORNECEDOR">
<credenciado detalhes="true">
<identificacao>
<id>123</id>
</identificacao>
<identificacao>
<id>456</id>
</identificacao>
<identificacao>
<registro tipo="CNPJ">11222333000144</registro>
</identificacao>
<contato detalhes="true">
<endereco detalhes="true"/>
<responsavel detalhes="true"/>
</contato>
</credenciado>
• Procura de credenciados como pessoa física registrados em fevereiro de 2014,
sem detalhamento de telefones ou endereço, somente e-mail:
<registro tipo="CPF"/>
<periodo tipo="CRIACAO">
<de>2014-02-01T00:00:00</de>
<ate>2014-03-01T00:00:00</ate>
</periodo>
<contato>
</contato>
</credenciado>
• Procura de todos os fornecedores da família de produtos 0595 (veículos) ou 0600
(peças para veículos) no Rio Grande do Sul ou em Santa Catarina com

credenciamento válido (renovação de credenciamento realizada no ano

imediatamente anterior, considerando como uma consulta realizada à meia-noite
de 15 de setembro de 2015):
<periodo tipo="RENOVACAO">
<de>2014-09-15T00:00:00</de>
<ate>2015-09-15T00:00:00</ate>
</periodo>
<linhaFornecimento>0595</linhaFornecimento>
<endereco detalhes="true">
<uf>RS</uf>
<uf>SC</uf>
</endereco>
</contato>
</credenciado>
• Procura de todas as centrais de compras criadas em 2010 e autorizadas a
credenciar fornecedores, com todo detalhamento possível:
<consultarRequisicao inicio="0" quantidade="1000" credenciamento="CENTRAL_DE_COMPRAS">
<periodo tipo="CRIACAO">
<de>2010-01-01T00:00:00</de>
<ate>2011-01-01T00:00:00</ate>
</periodo>
<autorizacaoCredenciamento>FORNECEDOR</autorizacaoCredenciamento>
<endereco detalhes="true"/>
</contato>
</credenciado>
4.7.2.2. Criar
Integração disponível para abrir um processo de solicitação de credenciamento de
um novo fornecedor no sistema de Compras Eletrônicas RS. Para utilizar este serviço, é
necessário que o usuário de integração possua permissão de Credenciamento de
fornecedores. Esta permissão deve ser requisitada, pois não está no pacote padrão de
permissões concedidas para usuários de integração.
4.7.2.2.1. Dados
Para seu uso, é necessário que o sistema cliente seja capaz de informar, de uma
única vez, os campos abaixo:
• Identificação
◦ estrangeiro: indica se o fornecedor possui nacionalidade Brasileira (default:
false);
◦ registro: número dos documentos que identificam o fornecedor (CPF, CNPJ,

INSCRICAO_MUNICIPAL, INSCRICAO_ESTADUAL). CNPJ deve ser

informado para Pessoa Jurídica. CPF deve ser informado para Pessoa Física.
Para fornecedores estrangeiros, informar o número identificador com o tipo
CNPJ selecionado. Pessoa física estrangeira não está disponível para cadastro;
◦ razaoSocial: Razão Social do fornecedor. Obrigatório quando Pessoa Jurídica;
◦ nomeFantasia: Nome Fantasia do fornecedor. Obrigatório quando Pessoa
Jurídica;
◦ porte: identificação do porte da empresa. Obrigatório quando Pessoa Jurídica;
◦ nome: Nome da pessoa. Obrigatório quando Pessoa Física;
◦ e-mail: E-mail da pessoa. Obrigatório quando Pessoa Física;
• Endereço:
◦ logradouro
◦ numero
◦ complemento
◦ cep
◦ bairro
◦ cidade
◦ uf: sigla da UF
◦ Telefone:
▪ ddd
▪ número
▪ ramal
• linhaFornecimento: código da família que este fornecedor representa (Este
elemento pode ser repetido para informar mais famílias) (formato: 0000);
• Responsável (obrigatório para Pessoa Jurídica):
◦ nome
◦ cpf: (mesmo para empresas estrangeiras, é obrigatório um responsável com
CPF válido);
◦ e-mail
◦ Telefone
▪ ddd

▪ numero
▪ ramal
4.7.2.2.2. Casos de uso
Solicitação de credenciamento de Pessoa Jurídica:

<criarRequisicao>
<fornecedor>
<identificacao estrangeiro="false">
<registro tipo="INSCRICAO_MUNICIPAL">1111</registro>
<registro tipo="INSCRICAO_ESTADUAL">222</registro>
<razaoSocial>Fornecedor WS</razaoSocial>
<nomeFantasia>Fornecedor WS</nomeFantasia>
<porte>OUTROS</porte>
</identificacao>
<endereco>
<logradouro>teste</logradouro>
<numero>1</numero>
<complemento>casa</complemento>
<cep>91900000</cep>
<bairro>Tristeza</bairro>
<cidade>Porto Alegre</cidade>
<uf>RS</uf>
<telefone>
<ddd>51</ddd>
<numero>32334455</numero>
<ramal>4961</ramal>
</telefone>
</endereco>
<responsavel>
<cpf>11111111111</cpf>
<nome>Usuário Teste WS</nome>
<email>teste@procergs.rs.gov.br</email>
<telefone>
<ddd>51</ddd>

<ramal>4961</ramal>
</telefone>
</responsavel>
</fornecedor>
</criarRequisicao>
Solicitação de credenciamento de Pessoa Jurídica Estrangeira:

<criarRequisicao>
<fornecedor>
<identificacao estrangeiro="true">
<razaoSocial>Fornecedor WS Estrangeiro</razaoSocial>
<nomeFantasia>Fornecedor WS Estrangeiro</nomeFantasia>
<porte>OUTROS</porte>
</identificacao>
<endereco>
<numero>1</numero>
<cep>91900000</cep>
<uf>RS</uf>
<telefone>
<ddd>51</ddd>
<ramal>4961</ramal>
</telefone>
</endereco>
<responsavel>
<cpf>11111111111</cpf>
<nome>Usuário Teste WS</nome>
<telefone>
<ddd>51</ddd>
<ramal>4961</ramal>
</telefone>
</responsavel>
</fornecedor>

</criarRequisicao>
Solicitação de credenciamento de Pessoa Física:

<criarRequisicao>
<fornecedor>
<registro tipo="CPF">11111111111</registro>
<nome>Fornecedor PF</nome>
</identificacao>
<endereco>
<numero>1</numero>
<cep>91900000</cep>
<uf>RS</uf>
<telefone>
<ddd>51</ddd>
<ramal>4961</ramal>
</telefone>
</endereco>
</fornecedor>
</criarRequisicao>
4.7.2.2.3. Resposta
A resposta desta ação retorna o ID do fornecedor no sistema de Compras
Eletrônicas RS. Esta informação deve ser armazenada, pois será necessária no momento
do credenciamento.
<criarResposta id="15033">
<situacao>SOLICITADO</situacao>
</criarResposta>
4.7.2.3. Credenciar
A ação “criar” efetua a solicitação de credenciamento, mas o credenciamento só
será efetivado quando a ação “credenciar” for executada. Esta ação ativará o fornecedor

no sistema de Compras Eletrônicas RS. Para utilizar este serviço, é necessário que o
usuário de integração possua permissão de Credenciamento de fornecedores. Esta
permissão deve ser requisitada, pois não está no pacote padrão de permissões
concedidas para usuários de integração.
Para utilizar esta ação, basta enviar os seguintes dados:
• id: identificação do fornecedor no sistema Compras Eletrônicas RS;
• usuario: CPF do responsável pela liberação do credenciamento. Este
usuário deve estar cadastrado no sistema Compras Eletrônicas RS e
pertencer à Central de Compras do cliente logado.
4.7.2.4. Certificar
A ação “certificar” adiciona o Certificado de Fornecedor do Estado (CFE) ao
fornecedor informado. Para utilizar este serviço, é necessário que o usuário de integração
possua permissão de Credenciamento de fornecedores. Esta permissão deve ser
requisitada, pois não está no pacote padrão de permissões concedidas para usuários de
integração.
• id: identificação do fornecedor no sistema Compras Eletrônicas RS;
• usuario: CPF do responsável pela liberação do credenciamento. Este
usuário deve estar cadastrado no sistema Compras Eletrônicas RS e
pertencer à Central de Compras do cliente logado;
• codigo: código de identificação do CFE (formato: 0000000/0000);
• dataValidadeInicial: data em que o CFE começa a ser válido;
• dataValidadeFinal: data em que o CFE expira;
• processo: Processo relacionado à certificação do fornecedor.
4.7.2.5. Alterar
Este ponto de integração é disponibilizado para que seja possível manter atualizado
o cadastro do fornecedor. Para utilizar este serviço, é necessário que o usuário de
integração possua permissão de Credenciamento de fornecedores. Esta permissão deve
ser requisitada, pois não está no pacote padrão de permissões concedidas para usuários
de integração.
4.7.2.5.1. Dados
Os dados para alteração foram divididos em 4 grupos: Identificação, Endereço,
Linhas de fornecimento e Responsável. Esta divisão foi projetada para que não seja

necessário enviar todas as informações do fornecedor a cada alteração. Desta forma, se,
por exemplo, houver somente uma mudança de endereço, o cliente deste serviço pode
informar somente o grupo Endereço. Lembrando que quando um grupo for informado, ele
deve ser informado por completo; todos os dados daquele grupo serão validados.
Dados obrigatórios:
• id: identificação do fornecedor no Sistema de Compras Eletrônicas RS;
• situacao: situação do fornecedor (ATIVO ou INATIVO). Para descredenciar, inative
o fornecedor.
Identificação:
• registro: número dos documentos que identificam o fornecedor (CPF, CNPJ,
INSCRICAO_MUNICIPAL, INSCRICAO_ESTADUAL). CNPJ deve ser informado
para Pessoa Jurídica. CPF deve ser informado para Pessoa Física. Para
fornecedores estrangeiros, informar o número identificador com o tipo CNPJ
selecionado. Pessoa física estrangeira não está disponível para cadastro;
• razaoSocial: Razão Social do fornecedor. Obrigatório quando Pessoa Jurídica;
• nomeFantasia: Nome Fantasia do fornecedor. Obrigatório quando Pessoa Jurídica;
• porte: identificação do porte da empresa. Obrigatório quando Pessoa Jurídica;
• nome: Nome da pessoa. Obrigatório quando Pessoa Física;
• e-mail: E-mail da pessoa. Obrigatório quando Pessoa Física;
Endereço:
• logradouro;
• numero;
• complemento;
• cep;
• bairro;
• cidade;
• uf: sigla da UF;
• Telefone:
◦ ddd;
◦ número;
◦ ramal.

Linhas de fornecimento: elemento linhaFornecimento - código da família que este

fornecedor representa (Este elemento pode ser repetido para informar mais famílias)
(formato: 0000).
Responsável (válido somente para Pessoa Jurídica):
• nome;
• cpf: (mesmo para empresas estrangeiras, é obrigatório um responsável com CPF
válido);
• e-mail;
• Telefone:
◦ ddd;
◦ numero;
◦ ramal.
4.7.2.5.2. Casos de uso

- Inativação de fornecedor:
<alterarRequisicao>
<fornecedor id=”15032”>
<situacao>INATIVO</situacao>
</fornecedor>
</alterarRequisicao>
- Alteração de responsável de Pessoa Jurídica:

<alterarRequisicao>
<situacao>ATIVO</situacao>
<responsavel>
<cpf>11111111111</cpf>
<nome>Nome do novo responsável</nome>
<telefone>
<ddd>51</ddd>
<ramal>4961</ramal>
</telefone>
</responsavel>
</fornecedor>
- Alteração de e-email de Pessoa Física:

<alterarRequisicao>
<situacao>ATIVO</situacao>
<registro tipo="CPF">11111111111</registro>
<nome>Fornecedor PF</nome>
<email>novo-email@procergs.rs.gov.br</email>
</identificacao>
</fornecedor>
4.7.2.6. Excluir
A ação “excluir” remove o cadastro do fornecedor informado. É importante ressaltar
que o fornecedor só será excluído se não possuir nenhum histórico de ação no sistema.
Para utilizar este serviço, é necessário que o usuário de integração possua permissão de
Credenciamento de fornecedores. Esta permissão deve ser requisitada, pois não está no
pacote padrão de permissões concedidas para usuários de integração.
• id: identificação do fornecedor no sistema Compras Eletrônicas RS.
4.8. Falhas
As requisições aos serviços podem falhar por diversos motivos, que podem incluir:
• formato de dados incorreto (tipo de dados, tamanho, restrição de conteúdo);
• violação do formato XML;
• violação do contrato expresso pelo XML Schema Definition;
• violação de regras de validação internas ao Sistema de Compras Eletrônicas;
• falha interna no Sistema de Compras Eletrônicas;
• utilização de endereço URL incorreto para comunicação;
• indisponibilidade temporária do Sistema de Compras Eletrônicas.
A grande maioria destas falhas receberá uma mensagem de falha da requisição,
com o detalhamento relevante. Falhas de indisponibilidade temporária obviamente não
retornarão resposta, e utilização de endereços URL retornará respostas HTTP com código
404 e sem conteúdo.
As demais falhas receberão um objeto com o detalhamento da falha ocorrida,
normalmente com as informações necessárias para que o usuário do sistema ou a equipe
de desenvolvimento do sistema cliente resolva a falha. O objeto enviado possui o seguinte
formato, a exemplo de uma falha ocorrida durante uma operação de consulta a uma

oferta:
<soapenv:Fault xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<faultcode>soapenv:Server</faultcode>
<faultstring xml:lang="pt-BR">Ocorreu uma falha na execução da desta
operação</faultstring>
<detail>
<consultarFalha xmlns="http://procergs.rs.gov.br/coe/ws/oferta/2.1"
xmlns:ns2="http://procergs.rs.gov.br/coe/ws/falha/2.0">
<ns2:identificacao>EXC-09/12/2015-10:44:29-6090-
635038</ns2:identificacao>
<ns2:mensagem>cvc-datatype-valid.1.2.1: '123x' is not a valid value
for 'integer'.</ns2:mensagem>
<ns2:mensagem>Não são permitidas pesquisas de ofertas com data de
publicação anterior a 2014-01-01T00:00:00.000-02:00</ns2:mensagem>
</consultarFalha>
</detail>
</soapenv:Fault>
Este exemplo foi artificialmente construído demonstrando todos os elementos

possíveis de uma falha. Algumas características a serem ressaltadas, algumas implícitas
pelo XSD:
• faultstring: elemento obrigatório, parte da definição de falhas SOAP; pode conter
toda a descrição da falha, como em caso de credenciais de autenticação incorretas
ou operação desconhecida, ou conter uma mensagem mais genérica, usualmente
quando o elemento detail está presente;
• detail: elemento opcional, possui detalhamento da falha em seu nível mais preciso,
quando disponível; o elemento contido neste será sempre dependente do tipo de
operação executada (“consultar”, neste exemplo);
• identificação: elemento opcional, representa uma falha de maior seriedade ocorrida
internamente no Sistema de Compras Eletrônicas, possivelmente indicando um
bug; quando presente possuirá um código de falha interno único como o exibido
acima, permitindo a identificação rápida e precisa da falha ocorrida; tal codigo deve
ser utilizado pela equipe de desenvolvimento da central de compras ao entrar em
contato com a equipe do Sistema de Compras Eletrônicas para correção do
problema;
• mensagem: elemento opcional, possivelmente ocorrendo múltiplas vezes,
possuindo mensagens que descrevem a falha ocorrida, sendo estas de dois tipos:
◦ Mensagens geradas pelo parser de XML e validador baseado no XSD, como a
primeira exibida acima, indicando uma falha no formato dos dados do sistema
cliente; podem possivelmente indicar uma falha ou bug na implementação da
integração, pois foi permitido o envio de dados inadequados; estas mensagens
são apresentadas em inglês, pois ainda não foi feita a substituição das
mensagens destas ferramentas para o português;
◦ Mensagens geradas pelos mecanismos de validação do Sistema de Compras
Eletrônicas, como a segunda exibida acima; são mensagens destinadas

frequentemente aos usuários, possuindo descrição direta da regra violada, e

permitindo a correção da falha e o reenvio dos dados.
Toda informação recebida é potencialmente útil para a identificação da falha, tanto
para a equipe de desenvolvimento da central de compras quanto para o usuário final do
sistema cliente, e não possui qualquer grau de confidencialidade ou sigilo, dado o
conhecimento das informações transmitidas. Desta forma, sugere-se que toda a
informação contida nas mensagens de falha seja integralmente exibida ao usuário do
sistema cliente para autosserviço, assim como armazenada em logs ou outros
mecanismos de registro de eventos, para acesso pela equipe de desenvolvimento da
central de compras e eventualmente colaboração com a equipe do Sistema de Compras
Eletrônicas para identificação e correção de falhas em qualquer uma das partes do
serviço, cliente ou servidor.
4.9. Testes
Para testes de novas integrações em desenvolvimento e casos de uso similares, o
Sistema de Compras Eletrônicas possui um ambiente de homologação cuja utilização é
recomendada para os cenários de testes a serem operacionalizados em ambiente de
produção. As credenciais não são as mesmas do ambiente de produção, e serão
igualmente informadas pelo administrador responsável.
As URLs para os serviços em ambiente de HOMOLOGAÇÃO são as seguintes:
https://coe.hml.rs.gov.br/egov2/ws/oferta_3.0.wsdl
https://coe.hml.rs.gov.br/egov2/ws/credenciado_1.0.wsdl
Como sugestão, antes da implementação da integração entre os sistemas, é
conveniente a familiarização com o serviço oferecido de forma mais manual e direta, para
melhor e mais rápida compreensão dos dados envolvidos e seu formato, além da fácil
simulação de situações de erro e avaliação das respostas recebidas. Para tal, a utilização
de uma aplicação para comunicação via SOAP é recomendada. Existem diversas
alternativas possíveis, dentre elas o aplicativo SoapUI, disponível para Windows, Linux e
MAC OS X no seguinte endereço:
http://www.soapui.org/
5. Evolução
Diversos casos de uso são possíveis para os serviços web, em especial a consulta
de ofertas e credenciados, porém existe a possibilidade de que uma determinada consulta
não seja atendida, ou não seja possível de atender de forma satisfatória, ou que
determinados dados importantes não estejam sendo disponibilizados. Da mesma forma,
suporte a outros protocolos, formatos ou versões envolvidas nos serviços disponibilizados
são passíveis de avaliação e implementação.
Em qualquer situação similar, entre em contato com a equipe do Sistema de

Compras Eletrônicas com sua sugestão, para que seja avaliada e possivelmente
implementada, porém fica a critério do administrador responsável pelo portal na qual a
sua central de compras está credenciada, com o suporte da equipe do Sistema de
Compras Eletrônicas o julgamento da viabilidade, aplicabilidade ou prioridade de qualquer
modificação nos serviços web.
6. Contatos
Em caso de problemas técnicos, dúvidas ou sugestões, entre em contato com a
equipe do Sistema de Compras Eletrônicas por e-mail:
atendimento-coe@procergs.rs.gov.br
Para outras informações sobre serviços web disponibilizados para integrar com
seus sistemas, entre em contato com o administrador do portal no qual a sua central de
compras está credenciada. Informações para contato disponibilizadas no próprio portal na
seção “Fale Conosco”.


Manual técnico de webservices COE

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Manual técnico de webservices COE

Enviado por

Direitos autorais:

Formatos disponíveis

COE

SISTEMA DE COMPRAS ELETRÔNICAS

Praça dos Açorianos, s/n° - CEP 90010-340

PROCERGS – Companhia de Processamento de Dados do Rio Grande do Sul 2 / 44

PROCERGS – Companhia de Processamento de Dados do Rio Grande do Sul 3 / 44

e setores de tecnologia da informação, a correta implementação da integração com o

PROCERGS – Companhia de Processamento de Dados do Rio Grande do Sul 4 / 44

4.1. Geração de classes

PROCERGS – Companhia de Processamento de Dados do Rio Grande do Sul 5 / 44

Algumas das ferramentas possíveis são:

Para mais informações, leia a documentação do padrão no seguinte endereço:

4.3. Autenticação descentralizada

PROCERGS – Companhia de Processamento de Dados do Rio Grande do Sul 6 / 44

Para utilizar a autenticação descentralizada é necessário fazer uma solicitação

PROCERGS – Companhia de Processamento de Dados do Rio Grande do Sul 7 / 44

informação de fuso horário será desconsiderada;

4.5. Certificado digital

4.6. Tabelas de conversão

• Unidades de medida: https://www.compras.rs.gov.br/ws/unidades_de_medida.csv

PROCERGS – Companhia de Processamento de Dados do Rio Grande do Sul 8 / 44

PROCERGS – Companhia de Processamento de Dados do Rio Grande do Sul 9 / 44

◦ Título e descrição textual resumida do seu objeto;

PROCERGS – Companhia de Processamento de Dados do Rio Grande do Sul 10 / 44

documentação. Para sua melhor compreensão, observe a documentação presente em

PROCERGS – Companhia de Processamento de Dados do Rio Grande do Sul 11 / 44

relevante. Para maiores informações, leia a seção 4.8..

Modalidade Tipo de objeto Documentos obrigatórios

PROCERGS – Companhia de Processamento de Dados do Rio Grande do Sul 12 / 44

4.7.1.2.3.Anexar documentos após a publicação do edital

PROCERGS – Companhia de Processamento de Dados do Rio Grande do Sul 13 / 44

associado à oferta e seu nome e contato constarão publicamente na oferta como o

PROCERGS – Companhia de Processamento de Dados do Rio Grande do Sul 14 / 44

<consultarRequisicao inicio="?" quantidade="?" escopo="?">

PROCERGS – Companhia de Processamento de Dados do Rio Grande do Sul 15 / 44

PROCERGS – Companhia de Processamento de Dados do Rio Grande do Sul 16 / 44

(“OR”). Em outras palavras ao definir um filtro de “situação” e um de “período”, os

PROCERGS – Companhia de Processamento de Dados do Rio Grande do Sul 17 / 44

• Ao contrário do exposto anteriormente, múltiplos filtros de período em um mesmo

PROCERGS – Companhia de Processamento de Dados do Rio Grande do Sul 18 / 44

todas as situações finais que uma oferta (homologada, deserta ou cancelada) ou

PROCERGS – Companhia de Processamento de Dados do Rio Grande do Sul 19 / 44

podem ser acessadas de forma “nominal”.

PROCERGS – Companhia de Processamento de Dados do Rio Grande do Sul 20 / 44

Para esta requisição, serão retornadas as ofertas, seus lotes, os proponentes de

PROCERGS – Companhia de Processamento de Dados do Rio Grande do Sul 21 / 44

PROCERGS – Companhia de Processamento de Dados do Rio Grande do Sul 22 / 44

<consultarRequisicao inicio="0" quantidade="10000" escopo="PROPRIO">

O Sistema de Compras Eletrônicas faz a consulta e encontra um total de 3.673

<consultarResposta dataHora="2015-12-10T17:12:55-02:00" inicio="0" quantidade="1145"

<consultarRequisicao inicio="1145" quantidade="10000" escopo="PROPRIO">

PROCERGS – Companhia de Processamento de Dados do Rio Grande do Sul 23 / 44

O Sistema de Compras Eletrônicas repetirá a busca e encontrará (possivelmente)

<consultarResposta dataHora="2015-12-10T17:12:57-02:00" inicio="1145" quantidade="1206"

<consultarRequisicao inicio="0" quantidade="10000" escopo="PROPRIO">

PROCERGS – Companhia de Processamento de Dados do Rio Grande do Sul 24 / 44

menores, se assim desejar. Adicionalmente, o cálculo feito por trás da escolha da

PROCERGS – Companhia de Processamento de Dados do Rio Grande do Sul 25 / 44

PROCERGS – Companhia de Processamento de Dados do Rio Grande do Sul 26 / 44

PROCERGS – Companhia de Processamento de Dados do Rio Grande do Sul 27 / 44

4.7.1.8. Desfazer fase

PROCERGS – Companhia de Processamento de Dados do Rio Grande do Sul 28 / 44

• Justificativa: justificativa textual para a execução da ação desfazer fase.