Mudanças entre as edições de "Mobly"
(25 revisões intermediárias por 2 usuários não estão sendo mostradas) | |||
Linha 24: | Linha 24: | ||
• Venda à ordem (5.120 / 6.120) | • Venda à ordem (5.120 / 6.120) | ||
• Remessa por conta e ordem de terceiros (5.923 / 6.923) | • Remessa por conta e ordem de terceiros (5.923 / 6.923) | ||
Linha 36: | Linha 30: | ||
[[Arquivo:Fluxo_vendaOrdem_Mobly.png]] | [[Arquivo:Fluxo_vendaOrdem_Mobly.png]] | ||
== Importação do pedido de venda == | |||
É feito a importação comum, como venda direta, porém, a nota fiscal emitida será remessa para depósito temporário. | |||
== Remessa para Depósito temporário(NF1) == | == Remessa para Depósito temporário(NF1) == | ||
Linha 41: | Linha 39: | ||
Após importação do pedido de venda, deve ser emitido nota fiscal utilizando os CFOPs 5949/6949. Está é a única nota fiscal emitida pelo cliente. | Após importação do pedido de venda, deve ser emitido nota fiscal utilizando os CFOPs 5949/6949. Está é a única nota fiscal emitida pelo cliente. | ||
=== Configuração da Transação === | |||
Está transação deve movimentar estoque em poder de terceiros e não deve gerar receber. | |||
== Importação das demais notas fiscais(NF2, NF3, NF4 e NF6) == | == Importação das demais notas fiscais(NF2, NF3, NF4 e NF6) == | ||
Linha 46: | Linha 47: | ||
A NF5 é emitida pela Mobly para o consumidor final, conforme apresentado no fluxo acima. | A NF5 é emitida pela Mobly para o consumidor final, conforme apresentado no fluxo acima. | ||
=== Configuração das transações === | |||
==== Simples Faturamento para Entrega Futura(NF2) - Saída ==== | |||
Está transação não pode movimentar estoque e deve gerar receber. | |||
==== Retorno simbólico de mercadoria depositada em armazém geral(NF3) - Entrada ==== | |||
Está transação não pode movimentar estoque e não pode gerar receber. | |||
==== Remessa simbólica Venda à Ordem(NF4) - Saída ==== | |||
Está transação não pode movimentar estoque e não pode gerar receber. | |||
==== Remessa por Conta e Ordem de Terceiro(NF6) - Saída ==== | |||
Está transação deve movimentar estoque em poder de terceiros e não pode gerar receber. | |||
=== Configuração do layout de importação das notas fiscais === | |||
Através do cadastro da empresa, adicione o layout de importação '''TEK-> IMPORTAÇÃO NOTAS FISCAIS - LOTE XML''' e atribua valor '''Sim''' para '''Importação de Participante'''. Este passo serve para dizer ao sistema que a importação das pessoas devem ser atualizadas conforme a nota fiscal. | Através do cadastro da empresa, adicione o layout de importação '''TEK-> IMPORTAÇÃO NOTAS FISCAIS - LOTE XML''' e atribua valor '''Sim''' para '''Importação de Participante'''. Este passo serve para dizer ao sistema que a importação das pessoas devem ser atualizadas conforme a nota fiscal. | ||
Linha 58: | Linha 78: | ||
[[Arquivo:Importacao_NF_Empresa_2.png]] | [[Arquivo:Importacao_NF_Empresa_2.png]] | ||
=== Configuração da unit === | |||
Acesse a unidade de codificação de configuração configurar os seguintes campos: | |||
'''DiretorioXmlNotasFiscais''': Informando o diretório onde será salvo os XMLs importados. | |||
'''VendaOrdem_canal_EmiteNF''': Informar valor True. | |||
Atenção: Deve ser um diretório acessível pela máquina do usuário e também pelo servidor. | |||
Exemplo: "DiretorioXmlNotasFiscais": "D:\\Tek-System\\Temp\\NFE" | |||
=== Importação das notas fiscais === | |||
A importação das notas fiscais são realizadas através do processamento específico '''TEK-> APIECOMMERCES: IMPORTAR XML NF EMIT CANAL RAZAO DA EMP'''. Também é possível realizar agendamento(a cada 1/2 horas) da importação informando o método '''TEK_APIECOMMERCES_VENDAORDEM_NF_EMIT_RAZAO_EMP.ImportarNotaFiscal('NOME DO CANAL')''' | |||
Importante: Cadastre corretamente o email/nome do usuário para receber notificações de qualquer problema durante movimentação de estoque, geração de financeiro, etc. | |||
A cada nota fiscal cancelada, será feito a consulta a sefaz para confirmação do cancelamento e obtenção do protocolo de cancelamento para atualização destas informações na nota fiscal | |||
Também é possível realizar a importação através dos arquivos XMLs. Para isso é necessário acesso ao módulo Livro Fiscal através do menu Integração > Importar Notas Fiscais. | |||
Informe o layout chamado '''TEK-> IMPORTAÇÃO NOTAS FISCAIS - LOTE XML'''. | |||
Ao clicar em '''Interpretar''', será exibido as pessoas envolvidas nas notas fiscais, as respectivas nfs e os itens. | |||
[[Arquivo:Importacao_NF_diretorio.png]] | |||
== Replicação de Pedidos entre empresas == | |||
Objetivo: Replicar pedidos de vendas incluídos em uma empresa para outra empresa da base de dados. | |||
Exemplo de uso: Replicar pedidos de vendas incluídos na empresa filial através da integração Drophipping Mobly na empresa Matriz. | |||
Pré-requisitos: | |||
a) Necessário liberação de uso da funcionalidade pela Tek-System; | |||
b) Necessário criar unidade de codificação com configurações de replicação de pedidos. | |||
Como realizar a configuração: | |||
É disponibilizado o processamento específico “REPLICADOR_PEDIDO_ENTRE_EMPRESAS” que pode ser executado manualmente. Na primeira vez que for executado será apresentada mensagem semelhante à imagem abaixo, solicitando a criação e configuração da unidade de codificação de configuração. | |||
[[Arquivo:Processo_Configurar_ReplicarPedidosEntreEmpresas_01.png]] | |||
Deverá, portanto, ser criada na TekStore as configurações pertinentes à cada parceiro Tek-System que opte em usar o processamento, conforme imagem ilustrativa abaixo: | |||
[[Arquivo:Processo_Configurar_ReplicarPedidosEntreEmpresas_02.png]] | |||
Nessa unidade de codificação deverão ser modificados e definidos o valor padrão das seguintes propriedades: | |||
a) "CodigoEmpresaOrigem":"-1" | |||
Deverá conter o código das empresas de ORIGEM das quais serão filtrados os documentos(pedidos). Admite-se mais de uma empresa, para isso basta separá-las com vírgula. | |||
Exemplo: "CodigoEmpresaOrigem":"2,3" | |||
Indica que serão lidos os documentos (pedidos) originalmente cadastrados nas empresas 2 e 3. | |||
b) "CodigoOrgaoOrigem":"-1" | |||
Deverá conter o conjunto dos órgãos ORIGEM para filtro dos documentos (pedidos). Admite-se mais de um órgão, para isso basta separá-los com vírgula. | |||
Exemplo: "CodigoOrgaoOrigem":"12,13,14" | |||
Indica que serão lidos os documentos cujos órgãos sejam 12, 13 ou 14. | |||
c) "CodigoTagReplicarItem":-1 | |||
Define o código da tag característica "CONSIDERAR_ITEM_REPLICACAO_PEDIDOS" que estabelece se o item será ou não replicado. | |||
Exemplo: "CodigoTagReplicarItem":45 | |||
A atribuição conforme exemplo acima, representa que será considerado o conteúdo da tag característica 45, que determinará se o item será considerado ou não na replicação do pedido. | |||
Exemplo de cadastro da tag característica. | |||
[[Arquivo:Processo_Configurar_ReplicarPedidosEntreEmpresas_03.png]] | |||
[[Arquivo:Processo_Configurar_ReplicarPedidosEntreEmpresas_04.png]] | |||
[[Arquivo:Processo_Configurar_ReplicarPedidosEntreEmpresas_05.png]] | |||
A utilização da tag é opcional, se seu valor for zero, indica que não haverá restrição na replicação dos itens, isto é, todos os itens serão considerados. | |||
Exemplo: "CodigoTagReplicarItem":0 | |||
Em quais situações a tag deverá ou não ser utilizada? | |||
Por exemplo, se a empresa possuir uma filial e-Commerce e através dela são vendidos itens de fabricação própria e também revendidos itens adquiridos de terceiros. Nessa situação é interessante que a empresa use a tag característica, estabelecendo que apenas itens de fabricação própria serão considerados na replicação de pedidos da filial (e-Commerce) para a matriz (indústria) que é a responsável pela fabricação dos mesmos. Itens adquiridos de terceiros não necessitam ser replicados porque não passam pelo processo de fabricação na matriz, a entrada em estoque ocorre via compra. | |||
d) "EmailNotificacao":"" | |||
Define o endereço de e-mail destinatário das informações relacionadas à execução do processamento. | |||
Exemplo: "EmailNotificacao":"exemplo@teksystem.com.br" | |||
e) "UsuarioNotificacao":"" | |||
Define o nome do usuário proprietário do endereço de e-mail definido no passo anterior. | |||
Exemplo: "UsuarioNotificacao":"NOME_DO_USUARIO" | |||
f) Os atributos abaixo possuem o mesmo princípio de funcionalidade: | |||
a. "TransacaoOrigemDestino": Define qual código de transação será atribuída ao pedido replicado na empresa destino. | |||
b. "TabelaPrecosOrigemDestino": Define o código da tabela de preços que será atribuída cujos valores serão considerados; | |||
c. "CondicaoPagtoOrigemDestino": Define o código da condição de pagamento que será atribuída e considerada; | |||
d. "TrocarClienteOrigemDestino": Define se haverá troca do código do cliente pelo código da pessoa vinculada à empresa de origem do pedido, em eventual necessidade. | |||
Caso seja “true” o faturamento será da matriz para filial, caso contrário, será da matriz direto ao cliente do pedido original. | |||
Essas propriedades têm comportamento comum, a nomenclatura dos atributos determina o comportamento a ser adotado na replicação, sendo formado pelo prefixo “Emp_” seguido do código das empresas origem e destino da replicação. | |||
Considere o formato de exemplo "Emp_XXX_YYY":Z, onde: | |||
XXX é a empresa de Origem; | |||
YYY é a empresa de destino; | |||
Z é o valor a ser aplicado. | |||
Vamos a um exemplo concreto definindo a propriedade “TransacaoOrigemDestino”: Conforme a nomenclatura, define a transação a ser aplicada na replicação do pedido da empresa de origem na empresa destino: | |||
"TransacaoOrigemDestino":{ | |||
"Emp_002_001":50, | |||
"Emp_003_001":51 | |||
} | |||
No exemplo acima temos a definição para dois comportamentos a serem adotados na replicação de pedidos. | |||
A primeira configuração "Emp_002_001":50 indica que pedidos de origem na Empresa 002 destinados à empresa 001 receberão como padrão a transação 50. | |||
A segunda configuração "Emp_003_001":51 indica que pedidos de origem na Empresa 003 destinados à empresa 001 receberão como padrão a transação 51. | |||
Esse mesmo princípio de funcionamento será adotado nos demais atributos do arquivo de configuração (TabelaPrecosOrigemDestino, CondicaoPagtoOrigemDestino e TrocarClienteOrigemDestino). | |||
A única diferença é que no último atributo, o conteúdo de definição se vai ser trocado o cliente do pedido, é um valor boleando (true ou false). | |||
A seguir um exemplo de um arquivo de configuração completo, definindo o comportamento para apenas uma empresa de origem dos pedidos de código 25 na replicação dos pedidos para empresa de destino código 1. Considerando apenas filtro de pedidos com órgão 12. | |||
{ "CodigoEmpresaOrigem":"25", | |||
"CodigoOrgaoOrigem":"12", | |||
"CodigoTagReplicarItem":45, | |||
"EmailNotificacao":"exemplo@teksystem.com.br", | |||
"UsuarioNotificacao":"MARCOS", | |||
"TransacaoOrigemDestino":{ | |||
"Emp_025_001":50 | |||
}, | |||
"TabelaPrecosOrigemDestino":{ | |||
"Emp_025_001":281 | |||
}, | |||
"CondicaoPagtoOrigemDestino":{ | |||
"Emp_025_001":19 | |||
}, | |||
"TrocarClienteOrigemDestino":{ | |||
"Emp_025_001":true | |||
} } | |||
Embora esse processamento possa ser executado sob demanda, ou seja, o próprio usuário pode executá-lo quando desejar, o ideal é que sejam criados agendamentos para que o processamento seja gerado automaticamente, sem necessidade de intervenções de usuários. | |||
A seguir, exemplo da chamada do processamento para ser adicionado em uma rotina de agendamento: | |||
C:\multicamadas2006\Exec\Servidor\ExecMetodoInterpERP.exe | |||
-T:20D5AFAA-YYYY-4A24-XXXX-C3519FA99717 -P:5700 -E:1 -M:TEK_REPLICADOR_PEDIDO_ENTRE_EMPRESAS.REPLICARDOCUMENTO; |
Edição atual tal como às 11h57min de 21 de junho de 2023
Nome do canal para configurações: MOBLY
O que é sincronizado?
- Estoque do Produto
- Importação de Pedido
Venda a Ordem
- Importa XML de notas fiscais emitidas pela Mobly em razão da empresa
- Importação de notas fiscais canceladas pela Mobly em razão da empresa
Processo no qual a Mobly fica responsável pela emissão de notas fiscais em razão da empresa(nosso cliente).
As CFOPs envolvidas no processo, são:
• Remessa para depósito (5.949 SP / 6.949 Demais UFs) • Simples faturamento (5.922 / 6.922) • Retorno simbólico de depósito temporário (1.949 SP / 2.949 Demais UFs) • Venda por conta e ordem (5.118 / 6.118 ou 5.119 / 6.119) • Venda à ordem (5.120 / 6.120) • Remessa por conta e ordem de terceiros (5.923 / 6.923)
Veja o fluxo abaixo:
Importação do pedido de venda
É feito a importação comum, como venda direta, porém, a nota fiscal emitida será remessa para depósito temporário.
Remessa para Depósito temporário(NF1)
Após importação do pedido de venda, deve ser emitido nota fiscal utilizando os CFOPs 5949/6949. Está é a única nota fiscal emitida pelo cliente.
Configuração da Transação
Está transação deve movimentar estoque em poder de terceiros e não deve gerar receber.
Importação das demais notas fiscais(NF2, NF3, NF4 e NF6)
A NF5 é emitida pela Mobly para o consumidor final, conforme apresentado no fluxo acima.
Configuração das transações
Simples Faturamento para Entrega Futura(NF2) - Saída
Está transação não pode movimentar estoque e deve gerar receber.
Retorno simbólico de mercadoria depositada em armazém geral(NF3) - Entrada
Está transação não pode movimentar estoque e não pode gerar receber.
Remessa simbólica Venda à Ordem(NF4) - Saída
Está transação não pode movimentar estoque e não pode gerar receber.
Remessa por Conta e Ordem de Terceiro(NF6) - Saída
Está transação deve movimentar estoque em poder de terceiros e não pode gerar receber.
Configuração do layout de importação das notas fiscais
Através do cadastro da empresa, adicione o layout de importação TEK-> IMPORTAÇÃO NOTAS FISCAIS - LOTE XML e atribua valor Sim para Importação de Participante. Este passo serve para dizer ao sistema que a importação das pessoas devem ser atualizadas conforme a nota fiscal.
No mesmo local acima, configure todas as transações seguindo o fluxo acima.
Importante: Caso esta configuração não seja feita, será utilizado a primeira transação encontrada na importação da nota fiscal
Configuração da unit
Acesse a unidade de codificação de configuração configurar os seguintes campos:
DiretorioXmlNotasFiscais: Informando o diretório onde será salvo os XMLs importados.
VendaOrdem_canal_EmiteNF: Informar valor True.
Atenção: Deve ser um diretório acessível pela máquina do usuário e também pelo servidor. Exemplo: "DiretorioXmlNotasFiscais": "D:\\Tek-System\\Temp\\NFE"
Importação das notas fiscais
A importação das notas fiscais são realizadas através do processamento específico TEK-> APIECOMMERCES: IMPORTAR XML NF EMIT CANAL RAZAO DA EMP. Também é possível realizar agendamento(a cada 1/2 horas) da importação informando o método TEK_APIECOMMERCES_VENDAORDEM_NF_EMIT_RAZAO_EMP.ImportarNotaFiscal('NOME DO CANAL')
Importante: Cadastre corretamente o email/nome do usuário para receber notificações de qualquer problema durante movimentação de estoque, geração de financeiro, etc.
A cada nota fiscal cancelada, será feito a consulta a sefaz para confirmação do cancelamento e obtenção do protocolo de cancelamento para atualização destas informações na nota fiscal
Também é possível realizar a importação através dos arquivos XMLs. Para isso é necessário acesso ao módulo Livro Fiscal através do menu Integração > Importar Notas Fiscais.
Informe o layout chamado TEK-> IMPORTAÇÃO NOTAS FISCAIS - LOTE XML.
Ao clicar em Interpretar, será exibido as pessoas envolvidas nas notas fiscais, as respectivas nfs e os itens.
Replicação de Pedidos entre empresas
Objetivo: Replicar pedidos de vendas incluídos em uma empresa para outra empresa da base de dados. Exemplo de uso: Replicar pedidos de vendas incluídos na empresa filial através da integração Drophipping Mobly na empresa Matriz.
Pré-requisitos: a) Necessário liberação de uso da funcionalidade pela Tek-System; b) Necessário criar unidade de codificação com configurações de replicação de pedidos.
Como realizar a configuração: É disponibilizado o processamento específico “REPLICADOR_PEDIDO_ENTRE_EMPRESAS” que pode ser executado manualmente. Na primeira vez que for executado será apresentada mensagem semelhante à imagem abaixo, solicitando a criação e configuração da unidade de codificação de configuração.
Deverá, portanto, ser criada na TekStore as configurações pertinentes à cada parceiro Tek-System que opte em usar o processamento, conforme imagem ilustrativa abaixo:
Nessa unidade de codificação deverão ser modificados e definidos o valor padrão das seguintes propriedades: a) "CodigoEmpresaOrigem":"-1" Deverá conter o código das empresas de ORIGEM das quais serão filtrados os documentos(pedidos). Admite-se mais de uma empresa, para isso basta separá-las com vírgula. Exemplo: "CodigoEmpresaOrigem":"2,3" Indica que serão lidos os documentos (pedidos) originalmente cadastrados nas empresas 2 e 3. b) "CodigoOrgaoOrigem":"-1" Deverá conter o conjunto dos órgãos ORIGEM para filtro dos documentos (pedidos). Admite-se mais de um órgão, para isso basta separá-los com vírgula. Exemplo: "CodigoOrgaoOrigem":"12,13,14" Indica que serão lidos os documentos cujos órgãos sejam 12, 13 ou 14. c) "CodigoTagReplicarItem":-1 Define o código da tag característica "CONSIDERAR_ITEM_REPLICACAO_PEDIDOS" que estabelece se o item será ou não replicado. Exemplo: "CodigoTagReplicarItem":45 A atribuição conforme exemplo acima, representa que será considerado o conteúdo da tag característica 45, que determinará se o item será considerado ou não na replicação do pedido.
Exemplo de cadastro da tag característica.
A utilização da tag é opcional, se seu valor for zero, indica que não haverá restrição na replicação dos itens, isto é, todos os itens serão considerados. Exemplo: "CodigoTagReplicarItem":0 Em quais situações a tag deverá ou não ser utilizada? Por exemplo, se a empresa possuir uma filial e-Commerce e através dela são vendidos itens de fabricação própria e também revendidos itens adquiridos de terceiros. Nessa situação é interessante que a empresa use a tag característica, estabelecendo que apenas itens de fabricação própria serão considerados na replicação de pedidos da filial (e-Commerce) para a matriz (indústria) que é a responsável pela fabricação dos mesmos. Itens adquiridos de terceiros não necessitam ser replicados porque não passam pelo processo de fabricação na matriz, a entrada em estoque ocorre via compra.
d) "EmailNotificacao":"" Define o endereço de e-mail destinatário das informações relacionadas à execução do processamento. Exemplo: "EmailNotificacao":"exemplo@teksystem.com.br"
e) "UsuarioNotificacao":"" Define o nome do usuário proprietário do endereço de e-mail definido no passo anterior. Exemplo: "UsuarioNotificacao":"NOME_DO_USUARIO"
f) Os atributos abaixo possuem o mesmo princípio de funcionalidade: a. "TransacaoOrigemDestino": Define qual código de transação será atribuída ao pedido replicado na empresa destino. b. "TabelaPrecosOrigemDestino": Define o código da tabela de preços que será atribuída cujos valores serão considerados; c. "CondicaoPagtoOrigemDestino": Define o código da condição de pagamento que será atribuída e considerada; d. "TrocarClienteOrigemDestino": Define se haverá troca do código do cliente pelo código da pessoa vinculada à empresa de origem do pedido, em eventual necessidade. Caso seja “true” o faturamento será da matriz para filial, caso contrário, será da matriz direto ao cliente do pedido original. Essas propriedades têm comportamento comum, a nomenclatura dos atributos determina o comportamento a ser adotado na replicação, sendo formado pelo prefixo “Emp_” seguido do código das empresas origem e destino da replicação. Considere o formato de exemplo "Emp_XXX_YYY":Z, onde: XXX é a empresa de Origem; YYY é a empresa de destino; Z é o valor a ser aplicado.
Vamos a um exemplo concreto definindo a propriedade “TransacaoOrigemDestino”: Conforme a nomenclatura, define a transação a ser aplicada na replicação do pedido da empresa de origem na empresa destino: "TransacaoOrigemDestino":{ "Emp_002_001":50, "Emp_003_001":51 }
No exemplo acima temos a definição para dois comportamentos a serem adotados na replicação de pedidos. A primeira configuração "Emp_002_001":50 indica que pedidos de origem na Empresa 002 destinados à empresa 001 receberão como padrão a transação 50. A segunda configuração "Emp_003_001":51 indica que pedidos de origem na Empresa 003 destinados à empresa 001 receberão como padrão a transação 51. Esse mesmo princípio de funcionamento será adotado nos demais atributos do arquivo de configuração (TabelaPrecosOrigemDestino, CondicaoPagtoOrigemDestino e TrocarClienteOrigemDestino). A única diferença é que no último atributo, o conteúdo de definição se vai ser trocado o cliente do pedido, é um valor boleando (true ou false).
A seguir um exemplo de um arquivo de configuração completo, definindo o comportamento para apenas uma empresa de origem dos pedidos de código 25 na replicação dos pedidos para empresa de destino código 1. Considerando apenas filtro de pedidos com órgão 12. { "CodigoEmpresaOrigem":"25", "CodigoOrgaoOrigem":"12", "CodigoTagReplicarItem":45, "EmailNotificacao":"exemplo@teksystem.com.br", "UsuarioNotificacao":"MARCOS", "TransacaoOrigemDestino":{ "Emp_025_001":50 }, "TabelaPrecosOrigemDestino":{ "Emp_025_001":281 }, "CondicaoPagtoOrigemDestino":{ "Emp_025_001":19 }, "TrocarClienteOrigemDestino":{ "Emp_025_001":true } }
Embora esse processamento possa ser executado sob demanda, ou seja, o próprio usuário pode executá-lo quando desejar, o ideal é que sejam criados agendamentos para que o processamento seja gerado automaticamente, sem necessidade de intervenções de usuários. A seguir, exemplo da chamada do processamento para ser adicionado em uma rotina de agendamento:
C:\multicamadas2006\Exec\Servidor\ExecMetodoInterpERP.exe -T:20D5AFAA-YYYY-4A24-XXXX-C3519FA99717 -P:5700 -E:1 -M:TEK_REPLICADOR_PEDIDO_ENTRE_EMPRESAS.REPLICARDOCUMENTO;