| Tarefa | Responsável | Breve orientação | Lição aprendida |
|---|
T1.01 - Instalar/Atualizar versão do Hotel | Cliente | - Essa integração está disponível a partir da versão v12.1.2210.08.
- Utilize sempre a versão mais atual.
- Durante projeto piloto, houveram melhoria nos pontos de entrada, para atender a integração VHF x POS.
- Portanto, caso o cliente, ou o profissional de serviços/suporte, tenha a versão mencionada acima instalada, e no portal, a versão seja superior. Orientamos que a versão seja atualizada.
- O processo de atualização do ambiente do cliente, para a versão mais recente do portal, será decisivo, para o sucesso da migração do VHF API para o BT VHF.
Linha revisada 04/11/2022. | Essa atividade deve ser executada com pelo menos 7 dias antes da migração do VHF API para o BT VHF. No primeiro hotel piloto, deixamos de atualizar previamente a versão, e no terceiro dia, tivemos inconsistência nos check-outs, e o BT VHF integrou lançamentos em contas encerradas. No segundo hotel piloto, da rede, houve uma dificuldade para realizar check-outs, e tivemos que nos deslocar presencialmente para o hotel. E ao chegar, o time constatou que a versão estava desatualizada.
|
| T1.02 - Mapear os pontos de atenção existentes na operação do hotel | Cliente TOTVS | - Atividade relevante para identificarmos alguma operação pontual que exista no hotel, e, que possa ser impactada com a migração do VHF API para o BT VHF.
- Os pontos identificados, devem ser reforçados com testes após a mudança do VHF API para BT VHF.
- Vale reforçar a disponibilidade do PO do produto para confirmar dúvidas ou particularidades encontradas.
Exemplos: - Integração entre POS e VHF lança na conta do hóspede os itens e não o TIPODC.
- Hotel utiliza direcionamento detalhado, aplicando restrição de valores, quantidade ou outra regra na tela de direcionamento da reserva.
- Hotel aplica desconto por grupo de cardápio.
- Hotel possui cartão consumo.
- Hotel grava cartão consumo antes da chegada no hóspede, no POS.
- Hotel possui ou não conta pendente integrando com o POS.
| Apesar da operação simplificada do hotel piloto, identificamos durante a migração, que o piloto não utilizava conta pendente.
Este comportamento "quebrou" a atualização das contas de check-in para check-out, e, toda vez que o hotel liberava um quarto para pendente, antes do check-out, as contas não eram "retiradas" do POS. Pontos que sugiram durante a entrevista dessa atividade: - Cliente utilizava desconto em contrato por tipo de débito e crédito.
- BT VHF atendia essa rotina.
- Contas eventos que não migravam no VHF API, e para isso, eram utilizadas contas avulsas, para depois transferir para a conta do evento.
- BT VHF atendia essa rotina.
Linha revisada 04/11/2022. |
| T1.03 - Hotel liberar acesso ao servidor de API | Cliente TOTVS | - Atividade necessária para testar a conexão ao servidor em que será feito o pré-setup do projeto.
- Recomenda-se utilizar ferramentas oficiais da TOTVS para realizar conexão no servidor de API do cliente.
- A execução dessa atividade será premissa para a validação e instalação do ambiente.
- A disponibilização desta conexão, permitirá uma migração remota.
Linha revisada 04/11/2022. | - Para o piloto, foi disponibilizado um hardware com os requisitos abaixo:
- Processador i5 / 16GB de memoria / Wind10 Pro
- Neste servidor o VHF API estava em execução antes de receber a instalação do BT VHF.
- Durante a execução do projeto, migramos 1 hotel. Para depois migrarmos outros 2.
- A conexão remota foi fundamental para que o time que realizou a migração, do VHF API para o BT VHF, antecipasse o pré-setup antes da chegada no cliente.
- O acesso ao ambiente, antecipadamente, permitiu testes e ajustes, que otimizaram o processo de migração.
|
| T1.04 - Validar ambiente do Servidor de API para instalação do BT VHF. | TOTVS | - Atividade necessária para garantir a estrutura das pastas determinadas como padrão TOTVS.
- O BT VHF deve ser instalado na pasta hotéis.
- Não existe conflito entre BT VHF e VHF API.
- Recomenda-se que não exista mais de uma pasta ..\TOTVS\HOTEIS.
- A reestruturação das pastas não deve ser realizada durante a migração.
- Qualquer ação para modificar as pastas do servidor de API do cliente, recomenda-se fazer 7 dias antes ou depois, da migração. Motivo: Evitar crises durante os primeiros dias da migração, e com isso, evitar rollback para o VHF API.
| - Para o piloto, tentamos unificar a estrutura da pasta TOTVS em uma só, porque o servidor de API do cliente tinha mais de uma pasta Hotéis.
- Tentamos realizar esta atividade no segundo dia da migração. E, o resultado não foi positivo. Em um determinado momento, o VHF API não conseguia mais abrir para integrar os dois hotéis que não haviam sido migrados para o BT VHF.
- Tivemos que retornar toda a estrutura de pastas. E, esta ação gerou gasto/perda de tempo do time sem necessidade para estabilizar um cenário que estava estável.
Linha revisada 04/11/2022. |
| T1.05 - Instalar |