OS 80246 - OBRIGAÇÃO FISCAL - SIS/WEB - DOC ELETRONICO - DESENVOLVIMENTO DO WEB SERVICE NOTAS FISCAIS DE SERVIÇO - VINHEDO

Objetivo:

Esta solicitação tem por objetivo Validar a implementação do Web Service de Notas Fiscais de Serviço (NFS-e) da prefeitura de Vinhedo, garantindo que:

• Os serviços do WS estejam corretamente integrados (getToken, getNextInvoice, getActivity, setInvoice, setCancelNfeOnly);

• Os controles de ambiente estejam respeitando a limitação de homologação (sem transmissões indevidas);

• Os retornos esperados sejam corretamente processados, exibidos e armazenados;

• A nova tela de testes execute os serviços e retorne os dados conforme esperado;

• A funcionalidade HABILITA_WEBSERVICE_VINHEDOativa, apenas para clientes que possuem cadastro de vinhedo e a funcionalidade wpWSVinhedo vinculada ao perfil do usuário;
  

  
  

  

Premissas:

• Necessário o ambiente estar atualizado com as versões:
  • Doc. Eletrônico de número 117553 Genexus 17 ou superior;

Teste realizado após a atualização

Cenário 1: Parâmetros iniciais e configuração

Passos:

1. Acesse o módulo Documento Eletrônico > Configuração > Cadastro de Parâmetros;
   

   
   

   

2. Clique em Inserir e selecione RPS_Vinhedo;
   

   

3. Defina o ambiente (produção ou homologação) e a versão;
   

   

4. Clique para editar o parâmetro;
   

   

5. Insira o Schema para o serviço getToken;
   

   
   
   
   

6. Clique em Senha RPS – Vinhedo e insira a senha fornecida pelo cliente.
   

   
   

   

   
   

Resultado Esperado:

• O parâmetro é salvo com sucesso.

• A senha do RPS é armazenada.

• O botão de senha só aparece para o tipo RPS_Vinhedo.

Cenário 2: Validação com funcionalidade inativa

Passos:

1. Com a funcionalidade ativa, acesse o menu NFS-e > Transmissão Vinhedo;
   

   

2. Será apresentada a mensagem Web Service inativo. Necessária transmissão via sistema da prefeitura de Vinhedo.
   

   

   
   

Cenário 3: Validação do serviço getToken

Passos:

1. Com a funcionalidade ativa, acesse o menu NFS-e > Transmissão Vinhedo;
   

   

2. Acesse a tela de teste WS Vinhedo;

3. Observe o ambiente informado (Homologação ou Produção);

4. Com a funcionalidade HABILITA_WEBSERVICE_VINHEDOativa, apenas para clientes que possuem cadastro de vinhedo e a funcionalidade wpWSVinhedo vinculada ao perfil do usuário.

5. Verifique a exibição da mensagem “Token de acesso WebService válido até...”;
   

   

6. Clique em Zerar Token e, em seguida, Confirmar para gerar novo token.
   

   

   
   

Resultado Esperado:

• Token é obtido e armazenado no cookie.

• Mensagens de erro são exibidas corretamente se inscrição ou senha estiverem ausentes, ou inválidas.

• Nova geração de token respeita o tempo de expiração de 15 minutos.
  

• Com a funcionalidade desligada, apenas o texto de Ambiente de Homologação é exibido.

Cenário 4: Validação do serviço getActivity

Passos:

1. Na tela de teste do WS Vinhedo, selecione a opção getActivity;

2. Clique em Confirmar.
   

   
   

Resultado Esperado:

• Grid é preenchido com as atividades retornadas pela prefeitura;

• Cada linha exibe código, descrição e tipo de ISS.

Cenário 5: Validação do serviço getNextInvoice

Passos:

1. Na tela de teste do WS Vinhedo, selecione a opção getNextInvoice;

2. Clique em Confirmar.
   

   
   

   

Resultado Esperado:

• É exibido o número da próxima nota disponível para escrituração.

Cenário 6: Verificação das opções de geração XML sem transmissão e com transmissão (Homologação)

Passos:

1. Com a funcionalidade ativa e ambiente configurado para Homologação;

2. Selecione nota(s) fiscal(is) e clique em Gerar XML para Transmissão.
   

Resultado Esperado:

• Sistema imprime relatório com destaque em vermelho indicando que se trata de homologação;

• Não há envio real da nota;

• Status de transmissão da nota não deve ser alterado;

• Mensagem de homologação aparece no topo da tela.

Observações Finais e Evidência de Sucesso

• Os relatórios gerados devem conter número da nota, atividade, alíquota e valor;

• As mensagens retornadas do WS devem aparecer no layout padronizado com quebras de linha (máx. 130 caracteres);

• Todos os XMLs gerados (transmissão/cancelamento) devem seguir o layout exigido pela prefeitura;

• O token deve ser validado em tempo real na tela de testes;
  

ATENÇÃO: As informações neste documento são meramente ilustrativas e utilizadas apenas para fins de teste.