> For the complete documentation index, see [llms.txt](https://docs.vrsoft.com.br/vrmaster/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.vrsoft.com.br/vrmaster/politica-de-atendimento.md).

# Política de Atendimento

## **DEFINIÇÕES**

* **BUGS –** Tem-se um bug quando algum processo do sistema está sendo executado de maneira incorreta, porém não está impedindo o usuário de continuar a trabalhar com o sistema. Por exemplo, um cálculo errado de uma tela, ou algum relatório desalinhado ou não condizente com a tela.
* \*\*ERROS – \*\*Tem-se um erro quando algum processo do sistema não está executando alguma ação. Por exemplo, ao finalizar uma nota o sistema apresenta erro null, ou numeric overflow. Lembrando que erros de mensagens não tratadas não devem ser considerados erros e sim solicitações. Por exemplo, ao excluir algum registro de uma tela e o sistema apresenta erro de chave estrangeira. Isso não é um erro, pois o sistema não permitiu o usuário excluir o registro, porém um tratamento pra que a mensagem seja diferente deve ser criado.

Qualquer outra alteração que modifique os processos do software, disposição de campos, mensagens, bem como seu funcionamento, deve ser encaminhado para a equipe de **Produto & Inovação** para um diagnóstico correto da necessidade.

### **FLUXO DE ATENDIMENTO**

O fluxo de atendimento, seja ele via Chat ou Telefone, segue o diagrama abaixo. Inicia-se no **Suporte**, onde o problema é reportado, se não for resolvido a equipe de **Produtos & Inovação** é envolvida e fará um contato com o cliente para diagnosticar o problema, caso um Bug e/ou Erro seja identificado esse diagnóstico com a solução é enviado a equipe de **Desenvolvimento**, onde uma versão com a correção será disponibilizado de acordo com o prazo de SLA para equipe de produtos que fará um novo contato para atualização do software.

![](/files/npcFt4TEU7u69sOronUH)

### **SLA's (desenvolvimento)**

Após concluída a fase de diagnóstico, pelo setor de **Produto & Inovação**, os bugs devem ser classificados considerando o impacto que está gerando na operação do cliente. De acordo com este impacto é determinada a Urgência conforme a tabela abaixo, e são definidos os prazos máximos para disponibilização da versão com a correção

| Urgência  | Impacto                 | Dias Úteis |
| --------- | ----------------------- | ---------- |
| Alta      | Parada de Operação      | 1          |
| Média     | Operação Prejudicada    | 3          |
| Baixa\*\* | Sem Impacto na Operação | 8          |

\*\*\*\*\* Os dias estão sendo considerados com base em 8 horas. \*\*\*\*\*\* Os tickets referentes a SPED/SEF/EDoc sempre serão classificados como Baixa urgência e os tickets devem ser abertos com no mínimo 8 dias uteis de antecedência a entrega do arquivo.

#### **EXEMPLOS**

* **Alta:** VRPdv sem vender, VRConcentrador não enviando preço, VRAutorizador off-line, erros na emissão de NF (exception), erro ao encerrar o dia, etc.
* **Média:** cálculo errado ao formular preço de um produto, erro ao importar xml de nota fiscal de entrada, problema ao consistir uma nota de saída, etc
* **Baixa:** valores divergentes entre telas, total em relatório não bate com a soma dos itens, nomenclatura de parâmetro incorreto, erros de ortografia, etc.

Todas as regras descritas anteriormente nesse documento têm por objetivo auxiliar no cumprimento desses prazos. Dessa forma, manteremos a satisfação do cliente por ter o seu problema resolvido rapidamente.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.vrsoft.com.br/vrmaster/politica-de-atendimento.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.