Mudanças entre as edições de "Politica de Atendimento"
De VRWiki
(→SUSTENTAÇÃO - BUGs, ERROS E SOLICITAÇÕES) |
(→SUSTENTAÇÃO - BUGs, ERROS E SOLICITAÇÕES) |
||
| Linha 5: | Linha 5: | ||
<Font size='5'>DEFINIÇÕES</font> | <Font size='5'>DEFINIÇÕES</font> | ||
| − | 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. | + | <b>BUGS –</b> 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. | + | <b>ERROS – </b>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 enviado para comitê para a aprovação, e posteriormente arquitetura e desenvolvimento. | Qualquer outra alteração que modifique os processos do software, disposição de campos, mensagens, bem como seu funcionamento, deve ser enviado para comitê para a aprovação, e posteriormente arquitetura e desenvolvimento. | ||
Existirão casos onde um Bug ou Erro, devido a sua complexidade ou custo (em horas de desenvolvimento), possa ser enviado para arquitetura. | Existirão casos onde um Bug ou Erro, devido a sua complexidade ou custo (em horas de desenvolvimento), possa ser enviado para arquitetura. | ||
| Linha 20: | Linha 20: | ||
<font color='red'>**</font>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. | <font color='red'>**</font>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 | + | <b>EXEMPLOS</b> |
| − | 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. | + | <b>Alta:</b> 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 | + | <b>Média:</b> 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. | + | <b>Baixa:</b> 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. | 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. | ||
Edição das 12h16min de 24 de fevereiro de 2017
No momento, nossa política de atendimento está sendo atualizada. Para evitar transtornos deixamos as informações desta página parcialmente off-line e estamos trabalhando para que possamos retornar as novas informações o mais breve possível.
SUSTENTAÇÃO - BUGs, ERROS E SOLICITAÇÕES
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 enviado para comitê para a aprovação, e posteriormente arquitetura e desenvolvimento. Existirão casos onde um Bug ou Erro, devido a sua complexidade ou custo (em horas de desenvolvimento), possa ser enviado para arquitetura.
SLA’s
Os bugs devem ser classificados pelos responsáveis do setor de desenvolvimento ou suporte, considerando o impacto que está gerando na operação do cliente. De acordo com este impacto é determinada uma “Urgência” conforme a tabela abaixo, e são definidos os prazos máximos para a solução do problema
*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.
