contato‎ > ‎suporte‎ > ‎

atualização do sistema

A Bematech utiliza uma metodologia inovadora de atualização de seu software Bematech ERP e que garante a seus clientes usufruírem das mais recentes novidades e melhorias que são liberadas mensalmente, além de trazer um elevado grau de estabilidade com a correções diárias e automáticas de defeitos.

Única versão do software Bematech ERP


A Bematech mantém uma única versão do software Bematech ERP, isso significa que nós corrigimos os defeitos de uma única versão do sistema, ao mesmo tempo que trabalhamos na próxima versão. 

Essa política permite a Bematech focar na estabilização dos softwares reduzindo o tempo gasto em correções de defeitos e consequentemente atendendo um maior volume de melhorias estratégicas dos clientes.

Minimizar as ocorrências de defeitos sempre foi um desafio para qualquer empresa que desenvolve sistemas, especialmente aquelas que desenvolvem um sistema de ERP, por ter características de sistema complexo e integrado: correções, alterações e implementações de melhorias podem ter reflexo em vários pontos do sistema.

As empresas que desenvolvem sistemas utilizam ferramentas, políticas, metodologias, capacitação e processos como forma de reduzir os riscos de entregar um sistema com defeitos ao mercado.

A Bematech dentro de sua metodologia de atendimento, procura fornecer sempre um sistema único, completo e estável. Mantendo uma única versão do software Bematech ERP, garantindo a atualização automática das correções de defeitos para seus clientes, mantendo-os satisfeitos entregando melhorias de forma cadenciada e frequente.

Internamente procuramos utilizar processos e metodologias de trabalho, tais como: Scrum, integração contínua, testes automáticos de unidade e de integração, testes funcionais realizados por profissionais qualificados, que garantam a qualidade do sistema.

O processo de atualização do software Bematech ERP pode ser dividido em dois:
  • Atualização Automática do Pacote de Correções
  • Atualização de Versão Final com Melhorias
Vamos explanar como funciona todo o processo de atualização, dos conceitos até os procedimentos que devem ser utilizados por nossos clientes para manter o sistema sempre atualizado com as últimas novidades.

Atualização Automática do Pacote de Correções

Esse tipo de atualização é importante para garantir a rápida estabilização do software Bematech ERP e consiste na opção de recebimento automático das correções dos defeitos da última versão final disponibilizada pela Bematech.

A atualização automática permite um melhor aproveitamento do tempo de todos, da Bematech e de quem recebe automaticamente as correções, porque mesmo as correções de defeitos não detectados por um cliente, são enviadas para todos os clientes daquela versão. Evitando o tempo de reportar o defeito e a gestão de liberação da correção.

A Bematech disponibiliza diariamente todas as correções na última versão final e envia para todos os clientes em forma de pacote de correções.

Melhorias são liberadas em versões finais fechadas

As melhorias desenvolvidas do software Bematech ERP são disponibilizadas na próxima versão, garantindo que a implementação seja liberada para o cliente de forma integrada com todas as melhorias e funcionalidades preexistentes do sistema. 

Esse é um grande diferencial para os clientes que possuem projetos em desenvolvimento, uma vez que receberão um sistema funcionando com compatibilidade com os avanços do sistema, seja em tecnologia ou em funcionalidades.

Versões curtas e frequentes

Um dos princípios das metodologias ágeis de desenvolvimento é a liberação de versões curtas e frequentes para reduzir o risco de impacto. A Bematech utilizando-se deste princípio utiliza o marco do "sprint" (ciclo de interação do Scrum que normalmente dura 30 dias e se inicia no dia 15 de um mês e termina no dia 14 do mês seguinte) para gerar uma versão do sistema com as melhorias concluídas na interação, mais precisamente no segundo dia útil do sprint seguinte.

Vale ressaltar que consideramos como melhorias concluídas, aquelas implementações que passaram pelos seguintes passos: solução analisada e confirmada, implementação de desenvolvimento, testes automáticos de unidade de código e de integração, revisão de código e testes funcionais integrados.

A nomenclatura das versões possuem o seguinte formato AAAA.S, onde AAAA será o ano e S o sprint da liberação, ex.: 2012.2 (2012 é o ano da liberação da versão e 2 indica que a versão foi liberada no início do segundo sprint do ano).

Atualização de Versão Final com Melhorias

Como política de atendimento da Bematech, todos os clientes tem direito às atualizações do software Bematech ERP, sejam de correções ou melhorias. Cabe ao cliente decidir quem fará a atualização. Se optar em contratar a Bematech para realização desta atividade, basta para isso a solicitação e agendamento do serviço de atualização através do Gerente de Projeto que o acompanha. É através do Gerente de Projeto que serão alocadas e coordenadas as atividades dos times para entrega da versão no ambiente do cliente na data programada. Caso opte por atualizar por conta própria, deve considerar os riscos inerentes a uma atualização de sistema.

Independente de quem faça a atualização, o backup antes de qualquer atualização é imprescindível e é responsabilidade do cliente (caso não tenha contratado o Serviço de Hospedagem). Alguma falha durante o processo de atualização pode ocorrer, que não é prevista nem contornável rapidamente e que acabe necessitando da restauração do backup para retornar o uso do sistema.

A cada início de sprint, os clientes que investiram no desenvolvimento de melhorias no sprint anterior tem até 7 dias para homologar as melhorias liberadas na versão daquele sprint, e para tanto devem realizar a atualização da versão em suas bases de desenvolvimento e homologação para as devidas adaptações e testes antes de colocar em produção.

Mais detalhes sobre como fazer a atualização do sistema serão abordados no texto abaixo. 

Testes frequentes

Nossa política de qualidade procura reduzir ao máximo o risco de entrega do sistema com defeitos. Mesmo com essa preocupação de nossa parte, é fator fundamental que nosso cliente possua sua própria política de testes antes da liberação do sistema para base de PRODUÇÃO. O cliente é co-responsável pelo sucesso de uma atualização de versão. O custo e risco de prejuízos são reduzidos quando são realizados os testes dentro do ambiente do cliente.

A realidade de configuração, customização e possibilidades de utilização do software Bematech ERP são diversas, muitas vezes impossibilitando prever todos os impactos de uma alteração e é por isso que há necessidade de validação dentro do ambiente do cliente.

Alguns clientes possuem políticas definidas para realização de testes, essas políticas podem envolver todos os setores da empresa que utilizam o sistema, outros podem optar por testes mais focados nas funcionalidades alteradas e outros apenas nos testes de operações críticas para empresa (cada empresa possui características que as diferenciam, portanto as operações críticas podem variar para cada uma). O importante é que os clientes tenham uma política definida de acordo com o nível de risco suportado pela empresa para as operações que são feitas no sistema.

Com esta sistemática de liberação frequente de versões (a cada sprint), o cliente precisa executar seus testes dentro de seu ambiente conforme sua própria política de testes a cada mês. O mesmo vale para as atualizações automáticas dos pacotes de correções, nas quais devem ser avaliados os graus de riscos das alterações.

Disponibilizamos a documentação de publicação das melhorias, alterações e correções, inclusive técnica. Ou seja, além das funcionalidades visíveis para o usuário final também são publicadas as alterações em APIs (Application Programming Interfaces) públicas e que podem ser utilizadas por códigos custom (exclusivos de um cliente).

Canais de atualização

A Bematech disponibiliza um canal de atualização para cada versão final. É através deste canal que todos os clientes podem obter a atualização do sistema.

No segundo dia útil de cada Sprint a Bematech divulgará a todos os clientes a liberação do novo canal daquela versão final, incluindo qual o seu endereço de Internet.

Estrutura necessária no cliente para atualização

A estrutura de bases considerada padrão para o ambiente dos clientes é:
  • Base NOMECLIENTE - Chamamos base de PRODUÇÃO do cliente. Esta base é utilizada para operações reais da empresa e deve ser mantida o mais estável possível. Esta base deve ser atualizada sempre que os testes realizados pelo cliente em suas bases M ou H sejam concluídos e liberados para atualização.
  • Base DNOMECLIENTE - Chamamos base D ou de DESENVOLVIMENTO do cliente. Esta base tem como objetivo manter o sequenciamento de chaves e desenvolvimento CUSTOM do cliente. Entenda como desenvolvimento CUSTOM as configurações e desenvolvimentos específicos para tornar o sistema adequado a realidade específica do cliente. Esta base deve ser atualizada automaticamente com os pacotes de correções e manualmente sempre que for disponibilizada uma nova versão final do software Bematech ERP no canal de atualização. Nesta base deve ser feito os testes e adaptações dos códigos CUSTOM com as melhorias/alterações/correções da versão. Essa base deve ser reconstruída, cópia da base de PRODUÇÃO, sempre que o desenvolvimento precisar de dados mais próximos da realidade da produção. No procedimento de reconstrução desta base é necessário o devido cuidado com o sequenciador de chaves de registros CUSTOM.
  • Base HNOMECLIENTE - Chamamos base H ou de HOMOLOGAÇÃO do cliente. Esta base tem como finalidade a realização de testes de homologação por parte dos usuários do cliente das melhorias e customizações concluídas, sejam elas desenvolvidas pela Bematech, pelo próprio cliente ou terceiros. Esta base deve ser reconstruída, cópia da base de PRODUÇÃO, sempre que os testes dos usuários precisem de dados mais próximos da realidade da PRODUÇÃO. Esta base deve ser atualizada a cada nova versão final do software Bematech ERP e as customizações implementadas na base D. 
  • Base MNOMECLIENTE - Chamamos base M ou de MANUTENÇÃO do cliente. Esta base é utilizada para o recebimento automático dos pacotes de correções e realizações de testes e deve estar vinculada ao canal de atualização da última versão final de sua base de PRODUÇÃO. Recomendamos que a cada atualização de nova versão final na base de PRODUÇÃO, esta base M seja recriada para ter uma realidade mais próxima da PRODUÇÃO para testes. Estes testes devem ocorrer conforme sejam recebidas as atualizações automáticas dos pacotes de correções e antes de enviá-las para a base de PRODUÇÃO.
Estas bases devem ser mantidas na estrutura do cliente (caso não seja contratado o serviço de Hospedagem) e é uma obrigação do cliente mantê-las atualizadas.

Todas as atualizações previstas aqui são completas, nenhuma atualização pontual deve ser feita, do contrário, o risco de criar um ambiente desconhecido e instável é maior.

Há clientes que não possuem projetos de investimento em melhorias no sistema e podem simplificar a estrutura para a existência de apenas duas bases:
  • Base MNOMECLIENTE - Unifica os conceitos das bases D, H e M da estrutura descrita acima.
  • Base NOMECLIENTE - Base de PRODUÇÃO conforme conceito descrito acima.
Vale ressaltar que, esta estrutura só é indicada para clientes que não possuem projetos de melhorias em andamento ou previstos para curto prazo e quando for retomado algum projeto, a estrutura padrão deve ser criada para que o fluxo de atualização seja cumprido para minimizar os riscos de instabilidade.

Fluxo de atualização


O processo apresentado na figura acima procura demonstrar o fluxo de atualização levando em consideração os canais de atualização disponibilizados e as bases no ambiente do cliente.

Uma Atualização de Versão Final com Melhorias deve ser disparada para base D do cliente para os devidos testes no sistema, configurações e implementações CUSTOM. O trabalho de adaptação das implementações CUSTOM deve ser avaliado pela publicação de melhoras/alterações/correções daquela versão e pelos testes realizados. Após essa atualização a equipe ServiceDesk da Bematech deve ser notificada por email, no endereço servicedesk.erp@bematech.com, de que a base D foi atualizada para que seja ligada a atualização automática do pacote de correções do canal da última versão final para a base D.

Após as adaptações ou conclusão de implementações CUSTOM na base D, é necessário atualizar a base H do cliente com origem na base D. Neste momento deve ser feito a medição do tempo de atualização para servir de referência para o tempo que será necessário para atualizar a base de PRODUÇÃO. Após atualização, os usuários podem realizar os testes da base H de acordo com a política de testes definida pela empresa.

Uma vez finalizado os testes e não apresentando nenhum problema na base H que impeça a atualização da base de PRODUÇÃO, esta deve ser atualizada originada da base H e logo em seguida a base M deve ser recriada como cópia desta base de PRODUÇÃO atualizada.

Quando a base M é recriada a equipe ServiceDesk da Bematech deve ser informada por email, no endereço servicedesk.erp@bematech.com, de que a base M está disponível para receber a atualização automática dos pacotes de correções da versão final em produção.

Diariamente a Bematech enviará para seus clientes um email com a publicação das atualizações automáticas do pacote de correções realizadas no dia. Será através deste email que os clientes devem realizar os testes das correções de acordo com sua política de testes na base M para posteriormente atualizar a base de PRODUÇÃO.

Atualização de versão final

Existem duas naturezas de atualização do software Bematech ERP, a atualização de versão final com melhorias e a atualização de versão final com correções. Nas seções abaixo, detalhamos como proceder em cada uma delas.

Atualização de versão final com melhorias

A Bematech está liberando uma versão nova de seu software Bematech ERP a cada mês, geralmente entre os dias 16 e 17. Cada nova versão liberada é feita sobre a disponibilização de uma nova base. O nome da nova base obedece ao formato AAAA-M, onde AAAA representa o ano com 4 dígitos e M o mês em questão. Desta forma, por exemplo, no ano 2012 e no mês de janeiro, a nova base terá o nome 2012-1. O endereço de cada base liberada também segue um padrão: versao.bematech.com:AAMM, onde o AA refere-se aos dois dígitos finais do ano e o MM representa o mês também com dois digítos. No exemplo da base 2012-1, o endereço seria versao.bematech.com:1201.

Essa nova versão mensal disponibilizada deve ser enviada para a base de desenvolvimento DCLIENTE. A seguir vem uma sequência de instruções para uma atualização bem-sucedida da base de produção com esta nova versão.

Após a atualização da base de desenvolvimento, o cliente deverá enviá-la à base HCLIENTE. Isso permitirá que os testes a serem feitos nestas bases sejam feitos sobre a nova versão liberada pela Bematech. É importante lembrar e seguir o fluxo correto de bases atualizadas. Neste momento de atualização de nova versão, a base DCLIENTE é utilizada para atualizar a base HCLIENTE. Aqui, ao se atualizar a base HCLIENTE, é imprescindível a seleção do produto CUSTOM. Dessa forma, a base de homologação estará atualizada com todos os produtos do software Bematech ERP e com todas as customizações do cliente. No processo de atualização, caso a seleção do produto CUSTOM não seja possibilitada por estar com a caixa de seleção desabilitada, uma rápida leitura no prefácio da documentação do cadastro de bases será o suficiente para o entendimento da causa e providências para a solução.

Em seguida, o cliente deverá testar o Sistema afim de validar todo o seu funcionamento na base de homologação, a base HCLIENTE. Após esta validação, é chegado o momento de se descartar a base MCLIENTE e se atualizar a base de produção a partir da base HCLIENTE. Uma vez que a base de produção tenha sido atualizada, a base MCLIENTE deverá ser recriada como uma cópia da base de produção. Este procedimento é útil pois mantém a base MCLIENTE com dados recentes da base de produção e, ao mesmo tempo, economiza uma atualização entre a base HCLIENTE e a base MCLIENTE. Aqui deve ser ajustado o cadastro de bases e a configuração das atualizações, pois a base trouxe, por cópia, o que havia sido feito para a base de produção.

Pronto. Feito isto, o ciclo volta ao normal, ou seja, a nova base MCLIENTE estará recebendo atualizações diárias com as correções dos produtos já na nova versão. É importante observar que a atualização para a base MCLIENTE é feita diariamente. Assim, logo após a disponibilização da nova versão, o cliente deverá estar atento, pois a base MCLIENTE já estará recebendo a nova versão a cada dia. Assim, após a liberação da nova versão, caso a base de produção seja atualizada a partir da base MCLIENTE, esta ação consistirá exatamente na atualização da base de produção com a nova versão. Como proteção, é importante que a base de produção não receba atualizações da base de manutenção enquanto o cliente estiver no circuito de atualização de nova versão, conforme descrito no parágrafo anterior.

Para saber em detalhes sobre como proceder para realizar a "atualização de versão final com melhorias", temos a seção "Como fazer esta atualização" um pouco mais abaixo, logo após a seção "Considerações finais sobre a atualização de versão final com melhorias e correções".  É importante observar que, na execução do processo "Atualizar Produtos", podem existir rotinas que são executadas automaticamente, outras manualmente, configurações ou verificações a serem feitas, etc. Tudo isso é informado pelo próprio processo através de um relatório com observações que devem ser levadas em consideração antes e/ou depois da atualização dos produtos. Essas rotinas, configurações e verificações visam garantir a compatibilidade do sistema com a nova versão e devem ser observadas com bastante atenção, pois algumas delas fazem manutenção na estrutura de tabelas do sistema, podendo exigir um tempo significativo de execução.

Atualização de versão final com correções

Diferentemente da liberação de melhorias, as correções no software Bematech ERP são disponibilizadas diariamente. A nova base, liberada em cada mês conforme explicado no tópico anterior, é também a base utilizada para a liberação destas correções. As correções são enviadas diariamente à base MCLIENTE através de uma atualização completa. Desta forma, um requisito de defeito para reportar uma falha no Sistema só deve ser criado se tal falha estiver ocorrendo também nesta base MCLIENTE. Caso o cliente deseje impedir temporariamente que uma base receba atualizações de outras, basta que haja pelo menos uma configuração de atualização e que ela seja desabilitada. O fluxo de bases atualizadas no caso desta atualizações de correções é bem mais simples, pois basta que a base de produção seja atualizada a partir da base manutenção: BEMATECH -> MCLIENTE -> PRODUCAO.

Considerações finais sobre a atualização de versão final com melhorias e correções

O cadastro de bases e a configuração das atualizações não são configurações requeridas para o funcionamento das atualizações do software Bematech ERP. Este cadastro e estas configurações apenas proporcionam, entre outros detalhes, um maior controle sobre quem estará autorizado à realizar as atualizações e qual fluxo será imposto. Caso o cliente opte por não controlar, o Sistema permitirá quaisquer tipos de atualizações e de qualquer origem; validando apenas se o usuário que está executando o upgrade participa do grupo Administradores e se está associado a uma política de segurança que o permita acesso remoto.

Um ponto importante a se observar é que, caso o cliente deseje controlar as atualizações recebidas, ele precisa estar sempre atualizando o seu cadastro de bases e a configuração das atualizações. Nestes casos, a base que vai receber a atualização (base de destino) precisa ter, em seu cadastro de bases, a base que vai enviar a atualização (base de origem). Nesta mesma base de destino, a regra de atualização deve ser aplicada à base de origem. Este detalhe está sendo ressaltado aqui pois, em casos de bases criadas como cópias de outras bases, este cadastro e configuração estarão defasados ou mesmo não serão aplicáveis à nova base criada. Em outras palavras, quando uma base for criada como cópia de outra, o cadastro de bases e a configuração das atualizações precisarão ser revistos.

Ainda em relação à configuração das atualizações, é de extrema importância e relevância os parâmetros "Permite atualizações de versões anteriores" e "Estágio mínimo de estabilidade". O ideal é que não seja marcado o parâmetro "Permite atualizações de versões anteriores", evitando regressões do Sistema e que, para o parâmetro "Estágio mínimo de estabilidade", seja selecionada a opção RELEASE, opção esta que representa o estágio mais estável de nossos produtos.

Atualização do sistema e as exigências fiscais e regulatórias

É de responsabilidade do cliente verificar quais os pré-requisitos fiscais e regulatórios para utilização e atualização do sistema. O cliente deve identificar quais atividades são exigidas para uma atualização, seja para serem feitas antes ou depois da atualização. Nos casos de atividades que a Bematech precisa realizar para o cliente, ele deve demandar através de requisitos em tempo hábil para sua execução.

Um exemplo de exigência que é pré-requisito para uma atualização, é o PAF-ECF, que depende de um procedimento cadastral da versão do sistema nas secretarias das fazendas dos estados que o exigem. Este cadastro é feito pela empresa desenvolvedora antes da utilização da versão pelos clientes. Os clientes que possuem estabelecimentos em estados que exigem tal procedimento, só poderão utilizar versões do sistema que estejam previamente cadastradas naqueles estados.

A Bematech, quando finaliza uma versão realiza todos os procedimentos exigidos pelas secretarias da fazenda para o cadastro da nova versão do PAF-ECF. Entretanto, a quantidade de documentos e procedimentos são diferentes entre as diversas secretarias, bem como, o prazo que elas levam para concluir o processo de cadastro, não sendo possível à Bematech mesurar o prazo para liberação das novas versões.

Veja mais detalhes sobre o PAF-ECF no tópico Atualização do PAF-ECF.

O Bematech ERP atende vários segmentos de mercado, como por exemplo, indústria, varejo, distribuidores, etc., com clientes com presença em vários estados brasileiros, mantendo uma única versão para todos estes segmentos e estados. Desta forma, o cliente precisa fazer as devidas verificações e consultas para proceder com a atualização da versão de forma adequada.

Atualização do PAF-ECF

Como mencionado no tópico Atualização do sistema e as exigências fiscais e regulatórias, o cliente só deve atualizar o PAF-ECF para uma versão que esteja cadastrada nas secretarias da fazenda dos estados que o exige. 

Desta forma, a atualização automática do PAF-ECF precisa ser desligada nos terminais de caixa dos estabelecimentos nos estados que utilizam a legislação PAF-ECF e o cliente precisa atualizar todos os terminais de forma manual a cada versão.

Para desligar a atualização automática:

  • Após o procedimento normal de instalação do sistema e com o sistema fechado (inclusive o iEngine);
  • Abra as propriedades do atalho do sistema;
    • Clique com o botão direito do mouse no atalho;
    • Clique em “Propriedades”;
  • Vá até a guia “Atalho”;
  • No campo “Destino” adicione ao final do conteúdo “ -nu” sem as aspas, como o exemplo abaixo:
    • C:\Engine\iEngine.exe demonstracao.bematech.com DEMONSTRACAO -nu
Para atualizar o PAF-ECF para última versão cadastrada no estado, descompacte o arquivo da versão correspondente dentro da pasta do sistema em cada terminal ECF:
Para clientes com a versão do PAF-ECF iguais ou inferiores a versão 2017.1, além dos procedimentos acima é necessário solicitar à Bematech a geração do arquivo PAF.ini através de requisito para a respectiva versão do PAF-ECF para cada terminal ECF. A geração do PAF.ini também é exigida na instalação de um novo ECF ou de um novo PDV ou caso o arquivo PAF.ini tenha corrompido.

O cliente deve conferir ao final da atualização se as informações de MD5 exigidas pela legislação do PAF-ECF estão devidamente cadastradas na secretaria da fazenda do estado daquele estabelecimento. Para conferir siga os seguintes passos:
  • Acesse o caixa 
  • Imprima o relatório Identificação PAF 
  • Efetue uma venda emitindo cupom fiscal 
  • Compare o MD5 do cupom e da Identificação PAF com o cadastrado na SEFAZ
Caso o MD5 não esteja igual ao da SEFAZ é necessário conferir os passos anteriores ou solicitar acompanhamento da Bematech para a verificação do procedimento.

Em toda atualização o cliente precisa realizar testes para verificar o comportamento do PAF-ECF em relação a versão do ERP, ou seja, devido a possibilidade de uso de uma versão do PAF-ECF anterior a versão do ERP é possível que algum comportamento não previsto ocorra e o cliente precise criar requisito de defeito se o motivo for pela diferença das versões.

Como fazer esta atualização

Após eleger a base origem para a atualização (sendo esta a base estável após a homologação do cliente / Bematech), deve-se acessar esta base via browser ou aplicativo (Engine) para realizar a atividade.

Caso a atualização seja realizada a partir da base da última base estável da Bematech, deve-se acessar a base 2017-8 através do endereço http://versao.bematech.com:1708, utilizando usuário “upgrade” e a senha "upgbematech".

Segue abaixo processo de atualização detalhado:

1. Realizar login na base ORIGEM para a atualização e acessar o processo Atualizar Produtos, em Bematech > Desenvolvimento > Atualização > Atualizar Produtos. O usuário em questão deve ter permissão para acessar o processo e realizar a atividade.


2. Após selecionar a opção "Atualizar Produtos", deve-se preencher os dados da base DESTINO da atualização, conforme consta na figura abaixo:


Os campos devem ser preenchidos seguindo a instrução abaixo:
  • Servidor: endereço da base DESTINO (ex: cliente.bematech.com) 
  • Base de Dados: nome da base no banco de dados (DNOMECLIENTE, HNOMECLIENTE, NOMECLIENTE)
  • Nome de Usuário: usuário na base DESTINO (usuário com permissão para executar o upgrade)
  • Senha: senha do usuário na base DESTINO
3. Após confirmado os dados de acesso do destino da atualização, caso a versão do aplicativo do destino este diferente do aplicativo da origem do upgrade será sugeriodo ao usuário a opção de atualizar o aplicativo, continuar sem aborta ou cancelar todo o processo, conforme mostra as imagem abaixo:
  1. Atualizar o Engine agora (recomendado).
  2. Continuar sem atualizar o Engine.
  3. Abortar este processo.


Caso o cliente seleciona a opção "Atualizar o engine agora (recomendado)." será realizada uma validação das permissões do usuário para verificar se as opções "Acesso remoto a partir de outra base" e "Permissão para reiniciar o Engine" estão habilitadas. Segue abaixo imagem das permissões que devem ser habilitadas para o usuário nas políticas de segurança (Bematech > Admin > Segurança > Política de segurança > Política de usuários).


4. Após acessar a base DESTINO para iniciar o upgrade, deve-se selecionar as licenças que serão atualizadas conforme mostra a figura abaixo. Favor atentar para as observações abaixo da imagem:




Observações:
  • A licença custom é bloqueada entre atualizações de bases da Bematech x clientes. Para atualizar esta licença entre bases de clientes deve-se habilitá-la no processo de Atualização, favor clicar aqui para acessar este manual.
  • Em todos os casos deve-se selecionar a caixa de texto Remover produtos não licenciados, evitando que script órfãos prejudiquem o funcionamento do software Bematech ERP.
5. Após selecionar os produtos que serão atualizados e clicar em Continuar serão informadas as Mensagens por Produto, deve-se observar cuidadosamente as mensagens informadas na atualização, algumas destas mensagens informam processos que devem ser executados para garantir a integridade dos dados após o upgrade. Outras mensagens são apenas informativas, alertando ao cliente sobre alterações dos processos após a atualização. Segue exemplo das mensagens no processo de upgrade:

Obs.: Orientamos aos usuários que ao visualizar as mensagens favor armazenar em um documento, para que em caso de falha na atualização o usuário tenha uma cópia das informações.

6. Após verificação entre as bases de origem e destino, o processo informa as mudanças estruturais que devem ser realizada na base destino. 
Seguem algumas observações sobre cada opção:
  • Em todos os casos de atualizações sejam Criados os Campos e Tabelas
  • No caso da Alteração do Tipo de Dados, orientamos que esta atividade seja realizada com a supervisão de um desenvolvedor que possua conhecimento técnico sobre a alteração.
  • No caso da Deleção dos Campos, orientamos que não seja marcada nenhuma opção desde que a equipe de desenvolvimento do cliente tenha ciência da exclusão, para que a integridade da base não seja prejudicada.




 
7. Após definir as alterações realizadas na estrutura de dados como criação, alteração e exclusão de campos e tabelas, o processo realiza verificação nas definições de criação e exclusão de índices: 
 
Orientamos o processo de Inserção e Deleção de Índices sejam realizados com a supervisão da equipe de banco de dados do cliente. Caso o cliente não tenha conhecimento para acompanhar esta atividade ou observar o impacto no banco de dados, pedimos que não seja marcada nenhuma opção. 

Lembro que a ausência de índices na base de dados podem tornar os processos lentos, prejudicando o uso. Caso as opções de criação e exclusão sejam marcadas, é aconselhável realizar uma atualização de estatísticas no banco de dados. 
  • Inclusão de índices: Devem ser selecionadas todas as opções de índices que o usuário deseja incluir. 
  • Exclusão de índices: Devem ser selecionadas todas as opções de índices que o usuário deseja deletar.  
  • Computar estatísticas: Favor verificar com o responsável pelo banco de dados a realização deste processo via SGBD.
  • Comprimir índices compostos: Caso exista índices compostos na base favor marcar esta opção para comprimir os objetos.
  • Criar índices online: Caso o banco do cliente suporte esta funcionalidade, esta opção deve está marcada.

8. Nesta etapa final, são mostradas as mensagens de conclusão do Upgrade, contendo as seguintes informações: endereço e nome da base de origem e destino, localização do arquivo de log referente ao processo, avisos e alertas complementares, licenças atualizadas, versões das alterações, mensagens do upgrade, classes irmãs com nomes iguais e arquivos e classes órfãos.

Todas as informações devem ser cuidadosamente observadas.
 


9. O processo para Atualizar o Engine, pode ser realizado caso esta atualização não tenha sido realizado no início do processo de Atualização de Produtos, conforme mostrado no tópico 1 deste texto. Este processo é semelhante ao passo 1 do upgrade e está localizado na árvore de navegação Bematech > Desenvolvimento > Atualizar iEngine, conforme exibido abaixo:


Os campos devem ser preenchidos seguindo a instrução abaixo:
  • Servidor: endereço da base DESTINO (cliente.bematech.com) 
  • Base de Dados: nome da base no banco de dados (DNOMECLIENTE, HNOMECLIENTE, NOMECLIENTE)
  • Nome de Usuário: usuário na base DESTINO (usuário com permissão para executar o upgrade)
  • Senha: senha do usuário na base DESTINO

10. Caso tenha sido realizada criação, alteração ou exclusão de campos e/ou o aplicativo iEngine.exe tenha sido atualizado é necessário reiniciar o serviço do software Bematech ERP em seu servidor de aplicativo.

11. Pronto! Basta observar a mensagem final e executar o que for solicitado.