Histórico da Página
Pré -Requisitos para a implementação:
Programas fontes |
envolvidos : |
|
LJRETAILWIZ.PRW - |
LJWIZAPP.PRW - 30/06/2017
| |
Sistema Operacionais: | Windows®/Linux® |
Banco de dados: | Todos Relacionais |
Servidor: | É recomendável um serviço ( appserver.ini ) separado para o RetailApp. |
Capacidade máxima da String | Conforme documentação: http://www.tdn.totvs.com/display/tec/MaxStringSize, é necessário alterar o tamanho da capacidade da string no appserver.ini conforme exemplo: [general]
maxStringSize=500 Incluir a chave TopMemoMega conforme documentação: http://tdn.totvs.com/display/tec/TOPMemoMega |
Certificado Digital: | A configuração do certificado digital é obrigatória para utilizar o protocolo seguro (HTTPS) , os detalhes da configuração que deve ser realizado no server do Protheus ( appserver.ini ) Antes de realizar a configuração é necessário verificar se o certificado está convertido: Conversão de certificados ‘PFX’ para ‘PEM’ – Windows Esse procedimento destina-se, exclusivamente, aos usuários do Sistema operacional Windows. Análise da cadeia de certificação Ao receber um certificado digital do tipo A1, antes da conversão para o formato PEM, recomenda-se a análise de alguns pontos importantes, para que não haja problemas com a conexão SSL3 e com a Secretaria de Fazenda. Primeiramente, é necessário instalar o certificado para visualizá-lo. O procedimento é feito da seguinte forma:
Algumas Secretarias de Fazenda exigem toda a cadeia da certificação para permitir a conexão SSL3. Caso o certificado seja instalado sem todos os certificados contidos na cadeia de certificação, o acesso é feito apenas em algumas Secretarias da Fazenda. Se isso ocorrer, siga os procedimentos já descritos a fim de solucionar o problema de conexão. Exportação do certificado digital Após concluir a análise do certificado digital, é necessário exportá-lo juntamente com a chave privada.
Conversão de certificados ‘PFX’ para ‘PEM’ – Linux Este procedimento destina-se aos usuários do Sistema operacional Linux. Para converter o certificado digital de ‘PFX’ para ‘PEM’ é necessário o utilitário ‘OpenSSL’. Acesse http://www.openssl.org/source/. Após instalar o utilitário ‘OpenSSL‘, execute os seguintes comandos:
Um exemplo de configuração no appserver.ini utilizado : [SSLConfigure] |
TRYPROTOCOLS=1 HSM=0 CertificateClient=C:\Protheus\Protheus_data\certificado\000002_all.pem KeyClient=C:\Protheus\Protheus_data\certificado\000002_key.pem |
Rotina no Menu:
Para iniciar o setup a rotina XXXX deve ser incluída no menu do Protheus .
Nesse( senha de acesso a chave privada ou certificado ) | |||||||||||||||||||||
Rotinas no Menu: |
Nesse link você encontra o passo a passo para incluir uma rotina no configurador (apenas exemplo) ( clique aqui ) |
seguindo ele você pode escolher
Parâmetros: |
MV_LJRAPP0 -
|
|
|
|
|
|
|
|
| |
Habilitar Campos | Para realizar a integração, necessário habilitar os campos reservados: F2_MSEXP.
8. Salvar a alteração. 9. Atualizar o dicionário. Para conferir o envio das informações para RetailApp, é necessário habilitar os campos reservados das tabelas SF1 (NF. Entrada), SA3 ( Vendedor), SB1 ( Produto e Estoque) e SE1 (Título a Reber - )
|
Passo 1 - Efetuando o setup inicial:
A rotina Setup Inicial (rotina LJRETAILSI ) tem a finalidade de efetuar a montagem da estrutura organizacional da empresa, conforme os passos abaixo:
- No Controle de Lojas (SIGALOJA) acesse Miscelânea
...
- / RetailApp Integração/Setup Inicial (rotina
...
- LJRETAILSI )
...
- .
...
- A primeira tela do Wizard de configuração será para a configuração da estrutura organizacional da empresa
...
1- Arquivos gerados na pasta :
- , ou seja, todas as lojas que aparecerão no app no nível hierárquico.
- Abaixo temos 2 exemplos de estruturas organizacionais: um exemplo de uma empresa com apenas uma loja e outro exemplo de um grupo com duas empresas e cada empresa com suas lojas:
Exemplo 1: Se a sua estrutura organizacional for igual a da imagem abaixo
A configuração será dessa maneira :
Exemplo 2:
Caso a estrutura da sua empresa seja assim :
No campo nível, é possível informar até o quarto nível, ou seja, de 1 a 4.
É necessário informar todos os níveis para continuar o setup.
Apenas no nível 4 deve informar as lojas (Empresa+Filial Protheus).
3. Na segunda tela do Wizard é necessário colocar o nome do usuário e e-mail que será o administrador do aplicativo, será utilizado para logar no portal ( https://admin.getretailapp.com )
e também receberá um e-mail cada atualização que for realizada :
Importante!
É necessário informar todos os campos para continuar o setup.
4. No último passo é o caminho que será gerado os arquivos de configuração, esse caminho é fixo, e não pode ser alterado.
5. Será gerado no caminho que por default está localizado em: Protheus_data\retailapp\inicial_files.
Ao final do processamento, é possível também salvar os arquivos, selecionando o caminho local.
Na tela abaixo você poderia salvar uma cópia localmente.
Importante
Caso tente acessar a rotina Setup Inicial( LJRETAILSI ), após ter concluído a montagem da estrutura organizacional, observe que é apresentada a seguinte mensagem:
Caso tenha necessidade de refazer ou ajustar a estrutura, apague os arquivos na pasta \retailapp\initial_files\ e refaça a estrutura organizacional da empresa.
6- Para facilitar o envio, compactar
...
a pasta com os arquivos.
Importante!
...
7 - Enviar um
...
e-mail para [email protected] com o arquivo .ZIP anexado para que seja criado a estrutura no app e você receberá o usuário com login e senha que será utilizado na próxima etapa da configuração.
Passo 2 - Efetuando Carga de Dados .
Pré-requisitos:
- Ter efetuado a montagem da estrutura organizacional na rotina Setup Inicial (rotina LJRETAILSI ).
- Ter recebido o e-mail com a confirmação da estrutura organizacional, o email/login e senhas de acesso para o app é necessário realizar a carga inicial, conforme instruções abaixo:
Importante! ![(informação)](/s/ougqdk/8804/xgjkrn/_/images/icons/emoticons/information.svg)
Antes de realizar a carga inicial, é necessário realizar uma verificação na base de dados com o intuito de não ter caracteres especiais que poderiam causar algum problema na integração.
Para facilitar essa verificação, revisar as seguintes tabelas: SB2 - Saldo Físico e Financeiro (B2_FILIAL, B2_COD, B2_QATU), SBM - Grupo de Produtos (BM_DESC), SA3 - Vendedores (A3_FILIAL, A3_COD, A3_NOME, A3_NREDUZ).
- No Controle de Lojas (SIGALOJA) acesse Miscelânea/ RetailApp Integração/Carga Dados (rotina LJRETAILDF ) .
- Nesse primeiro passo (Empresas/Filiais), selecione quais filiais devem gerar as cargas, conforme abaixo.
Por padrão, todas as filiais que foram cadastradas no Setup Inicial, serão apresentadas nessa tela e marcadas para geração das cargas.
É possível desmarcar as filiais que não forem gerar a carga.
Após selecionar as filiais, são apresentadas os endereços de comunicação com o app (Urls RetailApp).
Por padrão esses endereços (URL's), já são carregados. Porém caso haja alguma alteração nesses endereços, os mesmos podem ser alterados nesse momento.
4
...
. No próximo passo (Usuário de Conexão), é necessário informar as seguintes informações:
Informe e-mail (login) e senha do usuário que realiza a conexão com o app. (Informe o e-mail e senha, conforme informações do e-mail enviado pela RetailApp, confirmando a estrutura organizacional).
Observação! Esse usuário foi previamente cadastrado no Setup Inicial.
Informe todas as TES (códigos de Tipos de Entrada e Saída) que serão consideradas no filtro das vendas.
Observação! Somente as TES de saída são aceitas. Deve-se informar pelo menos um código.
Importante: Devido a limitação de tamanho do parâmetro(SX6) o local destinado para "códigos das TES", permite que seja informado User Function (customização) para retornar os códigos das TES separado por vírgula.
Exemplo:
User Function MinhaUserFunction()
Local cTes := '501,502,503'
Return cTes
Exemplo:
5. Nesse passo (Rotina Automática), é possível realizar a configuração automática da carga das vendas.
Para isso, é necessário marcar a opção de rotina automática e é imprescindível informar o tempo (minutos) entre uma execução e outra.
Importante!
Por padrão esse tempo, não pode ser inferior a 60 minutos.
É recomendável inserir as configurações automáticas no appserver.ini, pois caso não selecione a opção automática, a integração ocorrerá apenas de forma manual, sendo necessário executar a opção Executa Movimento da rotina Carga de Dados
Importante!
Ao informar os minutos para a atualização automática, o sistema grava no parâmetro MV_LJRAPP1, de forma que essa informação é apenas informativa. O que determina a atualização automática é a gravação do appserver.ini
Caso seja necessário alterar os minutos para atualização automática, será necessário alterar no appserver.ini.
Alteração dos minutos deve ser convertida em segundos, conforme exemplo abaixo:
Lembrando que a rotina automática deve ser configurada com no mínimo de 60 minutos = 3600 segundos
Atenção!
Após realizar a confirmação, é apresentada uma mensagem de aviso, solicitando a inclusão dessas informações no arquivo do servidor. Caso tenha outros serviços de rotinas automáticas já configuradas, não será possível incluir esse serviço automático.
É solicitado que seja configurado um servidor somente para esse serviço de carga (RetailApp). Essa configuração é necessária para que não entre em conflito com os outros serviços automáticos.
Após a confirmação, serão gravadas no arquivo appserver.ini as configurações necessárias para a rotina automática.
Exemplo:
[RETAILAPP]
Main=LJRetailApp
Environment=RETAIL
nParms=2
Parm1=99
Parm2=01
[ONSTART]
Jobs=RETAILAPP
REFRESHRATE=3600
Importante!
Quando a estrutura das lojas for por empresa, é necessário a configuração do Job também por empresa:
[RETAILAPP_01]
Main=LJRetailApp
Environment=RETAIL
nParms=2
Parm1=01
Parm2=01
[RETAILAPP_02]
Main=LJRetailApp
Environment=RETAIL
nParms=2
Parm1=02
Parm2=01
[ONSTART]
Jobs=RETAILAPP_01, RETAILAPP_02
REFRESHRATE=3600
6. No último passo (Período de Carga), é possível realizar a carga inicial ou executar a carga de x dias definido no campo "Dias para Processamento".
Inicialmente a primeira carga deve ser executada. Essa carga vai considerar todas as vendas dos últimos 12 meses.
Executa Carga Inicial: Ao executar a opção Executa Carga Inicial, o parâmetro MV_LJRAPP1, é atualizado com as seguintes informações:
- usuário (email) de conexão com o App | senha de conexão | quantidade de dias para o processamento (default = 001)| códigos das TES | minutos de intervalo.
Observações: caso a soma dos caracteres informados (E-mail e senha para conexão, TES, minutos de Job Automático e os dias para processamento) seja maior que a quantidade de caracteres permitida no parâmetro, é exibida uma mensagem alertando sobre a gravação das informações:
Executa Movimento: Após a carga inicial, esta opção pode ser utilizada se houver necessidade de enviar movimentações com quantidade de dias diferentes da configuração do parâmetro MV_LJRAPPI, que por default =001.
Campo Dias para Processamento: Deve informar a quantidade de dias que deseja enviar as informações para a RetailApp.
Exemplo:
Data da Venda 1: 05/07/2020
Data da Venda 2: 06/07/2020
Data da Venda 3: 07/07/2020
Data do sistema: 09/07/2020
Para enviar todas as vendas anteriores a data atual do sistema, no campo Dias para Processamento informe 004, com isso o sistema irá selecionar todas as vendas a partir do dia 05/07/2020. Este processo deve ser realizado caso a não tenha sido executado a movimentação durante o período do dia 05/07/2020 ao dia 09/07/2020.
Importante: Após a carga inicial, pode-se realizar a carga das últimas vendas, definindo a quantidade de dias no campo e clicando no botão "Executar Movimento"
Observe que após concluir a carga inicial ou a execução da opção Executa Movimento, são gerados os seguintes arquivos na Raiz do Protheus, Pasta RetailApp:
Os arquivos abaixo são apresentados com informações da última execução, não são gravados histórico de execuções:
- Inventory.json - Inventário - Nessa entidade são enviadas as movimentações de estoque para o aplicativo , os dados serão extraídos do arquivo de estoque ( SB2, SBM ) .
Observação: É necessário realizar o relacionamento do cadastro de Produto x Grupo de Produto para todos os produtos. Exemplo:
- Orders.json - Vendas - Essa entidade é responsável pelo envio das vendas realizadas no Protheus , com a seguinte regra, Todas as vendas ( SF2 ) da empresa corrente.Somente irá considerar as filiais na qual conter o arquivo de estrutura ( organization_structure.csv ).
- Orders_reserva.json - Reservas - Essa entidade é responsável pelo envio das reservas realizadas no Protheus , com a seguinte regra, todas as reservas ( SL1/SL2 ) da empresa corrente. Somente irá considerar as filiais na qual conter o arquivo de estrutura ( organization_structure.csv ).
- payments.json - Pagamentos - Essa entidade é responsável pelo envio dos títulos financeiro a receber ( SE1 ) para o app , os títulos enviados são apenas os títulos relacionados a vendas, com a seguinte regra :
- A vista : Títulos do tipo ( E1_TIPO ) dinheiro e cartão de débito.
- Meses : Todos os outros tipos diferentes de a vista ficaram nos campos de meses , a regra é a seguinte : Venda a venda são verificados os títulos (SE1) , se o vencimento
- Users.json - Vendedores - Esse arquivo é gerado com base nos vendedores da loja , com a seguinte estrutura : Nome : A3_NREDUZ , email : A3_EMAIL , código : A3_COD
...