Histórico da Página

T1.01 - Instalar/Atualizar versão do Hotel

• 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.
• Essa tarefa direciona a atualização das estações de trabalho. Para instalação/atualização do servidor de API, onde o VHF API estiver instalado/execução, faz-se necessário a leitura das orientações e lições aprendidas da linha T1.05.

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.

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.

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.

• 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.

Pacote necessário

• Worker / Robot (Hotal Monitor) / Plugins
• A instalação dos serviços/plugins acima, será premissa para o Go-Live do projeto. Sem essa atividade, os pontos de entrada e conexão entre VHF x POS x BT VHF não acontecerão.
  • Worker - Integrar os consumos e comunicar com a fila do POS.
  • Hotal Monitor - Realizar o monitoramento, e reiniciar o serviço Worker, caso ele trave ou caia.
  • Plug-ins - Realizar a integração dos quartos, contas, dados dos hóspedes, empresa e validação de mesa/consumos que estiverem em aberto no POS.
    • Interface BT VHF POS Chekout - Envia 
    • Interface BT VHF POS Consulta Status da Mesa
    • Interface BT VHF POS - Envia
    • Interface BT VHF POS Integração
    • Interface BT VHF POS Parâmetros
    • Ponto de entrada

• Entendemos durante a instalação e tentativa de unificar a estrutura de pastas do cliente, que, não podemos excluir a pasta …\TOTVS\HOTEIS, onde o VHF API estiver instalado/execução.
  • Caso exista mais de uma pasta ..\TOTVS2\HOTEIS, ..\TOTVS\HOTEIS2, ..\TOTVS\HOTEIS61131, e outras. Garanta que a pasta, em que o VHF API esteja em execução, não seja mexida/alterada.
  • Não executar o instalador da versão v12.1.2210.08 na pasta em que o VHF API estiver em execução.
  • Neste cenário, crie uma pasta ..\TOTVS\HOTEIS_BT, para receber a instalação da release nova e o BT VHF.
  • Durante o piloto identificamos que existe uma bpl, que causa conflito entre o VHF x VHF API x BT VHF. 
  • Separar o pacote com as versões mais novas, em uma nova pasta, foi a solução para evitar o travamento, a substituição e/ou perda do VHF API que se encontrava em produção no cliente.

IMPORTANTE:

• BT VHF ficou em execução, simultânea, com o VHF API durante 12 dias.
• Sem perda de performance. E;
• Não houve perda de consumo, travamento e/ou outras crises.

• Todo projeto de integração POS x BT VHF x VHF precisará de uma fila “on-line” para que o POS gere os consumos e o BT VHF leia e integre com o VHF.
• Essa atividade prevê a abertura de issue para o time de CLOUD.
• O responsável por este processo, é do time do POS, e para isto, precisa receber uma solicitação do time de serviço ou o profissional que estiver realizando o processo de migração/implantação.

IMPORTANTE:

• Atentar-se para o SLA.
• Precisa ser criada com antecedência a data em que acontecerá o Go-Live.

Exemplo da fila:

A fila abaixo é um exemplo e não funciona.

• A chave será disponibilizada via issue.
• Deverá ser incluída no parâmetro do BT VHF de acordo com TDN.

btvhf-invoice-integration-XbeRd999-4XEd-40ba-9WE7-0c42bOIn8be4-filaW