Histórico da Página
Integração Datasul x TOTVS Colaboração Recepção NF-e
Contexto de negócio
A oferta TOTVS Colaboração, compreende toda integração entre os ERP’s TOTVS com a solução NeoGrid. A responsabilidade do TSS (TOTVS Service SPED) no TOTVS Colaboração é de integrar os ERP’s com a NeoGrid, provendo serviços que possibilitem a comunicação e transmissão de documentos entre as partes.
Pré-Requisitos
- Contratação da Oferta do TOTVS Colaboração;
- TSS configurado para utilização das transações a serem utilizadas no TOTVS Colaboração.
Transação Recepção NF-e Entrada (Fornecedores)
Visão Geral
A integração referente à recepção de Notas fiscais eletrônicas (NF-e) de fornecedores abrange a utilização dos dados do XML da NF-e recebido dos fornecedores para geração de informações para automatização do recebimento (digitação) de notas fiscais dentro do ERP.
Entre as vantagens que esta integração proporciona, estão:
- Segurança: A nota poderá ser importada no recebimento logo após ser validada na SEFAZ o que garante a consistência e autenticidade das informações;
- Redução de Custos: Redução do volume de digitação de notas fiscais no Recebimento. Isso pode representar redução de custos de mão-de-obra para efetuar a digitação, bem como a redução de possíveis erros de digitação de informações;
- Previsibilidade: Planejamento de logística de recepção de mercadorias pelo conhecimento antecipado da informação da NF-e, pois a previsibilidade das mercadorias a caminho permitirá prévia conferência da Nota Fiscal com o pedido, quantidade e preço, permitindo, além de outros benefícios, o melhor uso de docas e áreas de estacionamento para caminhões;
- Redução de Erros: Redução de erros de escrituração devido à eliminação de erros de digitação de notas fiscais;
- Redução de Lead Time: Incentivo a B2B.
A recepção de NF-e de fornecedores, contempla a recepção, validação e tradução das informações inerentes ao negócio do fornecedor para informações de negócio do cliente.
Notas:
- Esta integração contempla o layout 2.0 da NF-e, sendo que a partir das releases definidas abaixo o sistema possibilita também a entrada do layout 3.10 da NF-e:
- Datasul 11 – Versão 11.5.10;
- EMS 2.06B – Pacote 2.06.C.07.
- O sistema não contempla a entrada/recepção de NFC-e (Nota Fiscal Eletrônica de Venda ao Consumidor Final), modelo 65;
A integração envolve o ERP (Datasul), TSS (TOTVS Service SPED), Neogrid e SEFAZ (Secretaria da Fazenda) e prevê dois fluxos: recebimento iniciado pelo ERP e recebimento iniciado pelo Neogrid, detalhados na sequência.
Recebimento iniciado pelo ERP
- Fornecedor envia o XML da NF-e para o cliente;
- ERP envia o XML da NF-e para o TSS;
- TSS envia XML da NF-e para validação;
- Neogrid valida a mensagem;
- Neogrid envia consulta de situação da NF-e a Secretaria da Fazenda;
- Secretaria da Fazenda processa consulta da situação da NF-e e retorna e resultado;
- Neogrid disponibiliza o retorno da consulta da NF-e;
- TSS busca XML da NF-e validado na Neogrid;
- ERP busca NF-e do TSS e efetiva no recebimento.
Recebimento iniciado pela Neogrid
- Fornecedor envia o XML da NF-e para o Neogrid;
- Neogrid valida a mensagem;
- Neogrid envia consulta de situação da NF-e a Secretaria da Fazenda;
- Secretaria da Fazenda processa consulta da situação da NF-e e retorna e resultado;
- Neogrid disponibiliza o retorno da consulta da NF-e;
- TSS busca XML da NF-e validado;
- ERP busca NF-e do TSS e efetiva no recebimento.
Pré-Requisitos da Integração dos Produtos
Contratação da oferta do TOTVS Colaboração;
TSS (TOTVS Service Sped) instalado e configurado para utilização.
Parametrização da Integração no Produto, Origem
Na instalação do TSS (que deve ser a versão igual ou superior à 2.07), selecionar o parâmetro “Recebimento de documentos” como serviço a ser utilizado do TOTVS Colaboração.
Para a recepção do layout 3.10 da NF-e, deverá estar instalada a versão do TSS que contempla a recepção desta versão de Layout.
Parametrização da Integração no Produto, Destino
Configuração dos parâmetros do conversor de NF-e entrada (RE0119);
Configuração do fornecedor, se deve ou não atualizar a NF-e automaticamente no recebimento (CD0401)
Configuração do engine de regras: O Engine de Regras possibilita configurar as condições externalizando a regra de negócio. Utilizar os programas CD0024 para cadastro das regras, CD0025 para cadastros de tipos de operação e CD0026 para testes.
As operações que podem ser cadastradas no Engine para conversão/sugestão de valores para entrada da nota no recebimento são apresentadas na sequência:
Tipo de Operação | Descrição |
serie-docto | Série do Documento |
cod-observa | Código Observação |
it-codigo | Código Item |
nat-operacao | Natureza Operação |
numero-ordem | Ordem Compra |
num-pedido | Pedido Compra |
parcela | Parcela Ordem |
nr-ord-produ | Ordem Produção |
cod-refer | Referência |
cod-depos | Depósito |
cod-localiz | Localização |
lote | Lote |
dt-vali-lote | Data Validade Lote |
un-xml | Unidade de medida do Item |
cod-emitente | Código do Emitente |
As variáveis que podem ser cadastradas no Engine de Regras para utilização nas regras são estas:
Variável |
Descrição |
Apresente quais as transações/entidades que são trocadas e quem envia a informação para quem. Pode (e recomenda-se) ter um diagrama, uma tabela ou afins que apresente este fluxo.
Relacione quais são as mensagem únicas (TOTVSMessage) utilizadas e qual o seu relacionamento com as entidades já existentes do ERPs envolvidos.
Exemplos:
Método | ID | Descrição | Origem | Destino | XSD (versões podem variar) |
Cadastros | 01 | Cliente/Fornecedor | RM | Protheus | CustomerVendor_1_000.xsd |
02 | Moeda | RM | Protheus | Currency_1_000.xsd | |
03 | Unidade de Medida | RM | Protheus | UnitOfMeasure_1_000.xsd | |
04 | Produto | RM | Protheus | Item_?_000.xsd | |
05 | Centro de Custo | RM | Protheus | CostCenter_1_000.xsd | |
06 | Ativos | RM | Protheus | NOVA, Ativo fixo | |
07 | Funcionários | RM | Protheus | Employee_1_000.xsd | |
08 | Projeto | RM | Protheus | Project_1_000.xsd | |
09 | Obra | RM | Protheus | SubProject_1_000.xsd | |
10 | Tarefa | RM | Protheus | TaskProject_1_000.xsd | |
11 | Meio de Pagamento | RM | Protheus | ?????.xsd | |
12 | Condições de pagamento | RM | Protheus | PaymentCondition_1_000.xsd | |
13 | Coligada* | RM | Protheus | Company_1_000.xsd | |
14 | Filial* | RM | Protheus | Branch_2_000.xsd | |
Processos | 15 | Solicitações (compras/armazém) | Protheus | RM | Request_1_000.xsd |
16 | Cancelar movimento (solicitação, OS, etc) | Protheus | RM | CancelRequest_1_000.xsd | |
17 | Cancelar movimento (solicitação, OS, etc) | RM | Protheus | CancelRequest_1_000.xsd | |
18 | Baixa de estoque | Protheus | RM | Request_1_000.xsd | |
19 | Baixa de estoque | RM | Protheus | Request_1_000.xsd | |
20 | Consulta Saldo | Protheus | RM |
| |
21 | Apropriação de custos |
|
| Request _1_000.xsd | |
22 | Geração de OS |
|
|
| |
23 | Consulta de OS |
|
|
| |
24 | Ampliação patrimonial |
|
|
|
Fluxo das Informações
Para cada fluxo de informação descreva, se necessário, alterações de comportamento que o respectivo produto irá sofrer. Por exemplo: quando o Logix recebe o PEDIDO de OUTRO ERP, este pedido não poderá ser alterado no Logix.
Liste quais as entidades integradas e como é o mapeamento entre as diferentes estruturas. Por exemplo: Classe no sistema A vira categoria no sistema B, o campo X é refletido no campo Y etc.
Liste quais transações/operações a integração fará com as entidades relacionadas. Exemplo: Insert de PEDIDO, Insert, update de ITEM, buscar saldo em estoque do ITEM no dia X ou buscar dados do FUNCIONÁRIO.
Cadastros
Descreva características gerais do fluxo de informações e que serão comuns para este tipo de entidade. Características particulares para cada entidade deverão ser citadas em tópicos específicos de cada entidade.
Sempre que existir (a sugestão é sempre criar) e for agregador ao documento acrescentar aqui os diagramas/imagens ou até mesmo colocar tais diagramas diretamente na especificação dos processos
Em seguida faça uma descrição para cada um dos fluxos para cada entidade
<Transação/Entidade>
Identificador da Mensagem: <mensagem>
Versão: <versão>
Módulo <marca 1>: <BackOffice – Gestão xxxxxxx>
Módulo <marca 2>: <SIGAXXX>
Tipo de Envio: <Assíncrona/Síncrona>
Mensagem Padrão | PROTHEUS | RM | ||
Tabela | Campo | Tabela | Campo | |
Code | CTO990 | CTO_SIMB | GMOEDA | SIMBOLO * |
Description | CTO990 | CTO_DESC | GMOEDA | DESCRICAO |
Symbol | CTO990 | CTO_SIMB | GMOEDA | SIMBOLO |
Notas:
Observações sobre comportamento desta mensagem ou dos processos envolvidos nela/para ela
A seguir descrever as variações, particularidades da mensagem e processos (integração) de acordo com cada marca
Limitações/Restrições
Descreva limitações e restrições para a integração que está sendo descrita.
Processos
Descreva características gerais do fluxo de informações e que serão comuns para este tipo de entidade. Características particulares para cada entidade deverão ser citadas em tópicos específicos de cada entidade.
Sempre que existir (a sugestão é sempre criar) e for agregador ao documento acrescentar aqui os diagramas/imagens ou até mesmo colocar tais diagramas diretamente na especificação dos processos
Em seguida faça uma descrição para cada um dos fluxos para cada entidade
<Transação/Processo>
Tipo de Fluxo: Protheus -> RM
Mensagem: Request_1_000
Versão: 1.000
Descrição de todo o comportamento e funcionamento do processo. Breve contexto, origem, regras, integração (geração da mensagem, envio, recebimento no destino), o quê supostamente irá ocorrer no destino, retorno, impacto, consequências, o que foi afetado, como conferir, validar, etc o retorno.
Acrescentar um diagrama do processo.
A seguir descrever as variações, particularidades da mensagem e processos (desta integração) de acordo com cada marca
Notas:
Observações sobre comportamento desta mensagem ou dos processos envolvidos nela/para ela
Limitações/Restrições
Descreva limitações e restrições para a integração que está sendo descrita.
Limitações / Restrições Gerais
Descreva limitações e restrições para cada fluxo descrito no tópico anterior. Exemplo:
- ERP1 envia ITEM cadastrado para o ERP2
ERP1 somente enviará o ITEM se este estiver em uma das famílias cadastradas no parâmetro FAMILIA_INTEGRACAO.
Se o tipo de valorização do estoque for FIFO.
- ERP2 envia PEDIDO cadastrado para o ERP1
O pedido recebido no ERP1 vindo do ERP2 estará bloqueado para alteração.
Como fazer (opcional)
Descreva os passos que viabilizem a integração.
Exemplo:
Os passos para viabilizar a integração são:
- No Logix ou no Protheus efetue o cadastro das seguintes informações: Clientes, fornecedores, transportadores, cidades, cotação de moeda e unidades de medida.
- No Logix cadastrar um novo depositante e efetuar toda a parametrização necessária para a operação de WMS.
- No Logix cadastrar um novo produto que seja controlado pelo WMS, para o depositante cadastrado anteriormente.
- No Logix efetuar um processo de recebimento para o produto cadastrado anteriormente, utilizando uma nota fiscal provisória (tipo “A”).
- No Protheus consultar a nota fiscal de recebimento que foi registrada no Logix, validando as informações recebidas.
- No Logix efetuar um processamento de regularização fiscal, efetuando a cobertura dos produtos recebidos anteriormente.
- No Protheus verificar se foi efetuado corretamente o relacionamento entre os dois documentos.
- No Logix efetuar um processo de expedição para o novo produto cadastrado, até o momento do envio da mensagem de integração de pedido de venda.
- No Protheus efetuar o faturamento do pedido de venda recebido.
- No Protheus verificar se a nota fiscal gerada contém todas as informações necessárias para o segmento de operador logístico (armazém geral).
- No Protheus efetuar a escrituração fiscal das notas fiscais, verificando se as regras da legislação deste segmento foram respeitadas.
- No Logix é possível consultar o número do pedido de venda gerado para as notas fiscais de retorno simbólico e conta/ordem no programa WMS6333 (Consulta de Documentos). Para os processos de faturamento de serviço o número do pedido está disponível no programa WMS6411 (Movimentos a Faturar).
Situações comuns (opcional)
Descreva situações problemáticas comuns que podem ocorrer durante o funcionamento da integração e como solucioná-los. Neste ponto também é importante dar instruções de como reconhecer e investigar problemas que podem vir a ocorrer durante a integração. Se houver, apresente tabelas de códigos e descrições de erros que a integração poderá apresentar.
Este tópico possivelmente será alimentado com as experiências durante o desenvolvimento da integração e poderá ser realimentado durante o uso da integração no cliente.
Exemplo 1:
Tratamento de erros de integração (Produto A)
Erro | Mensagem | Solução |
Código do erro | Mensagem exibida | Ação a ser tomada para resolução do erro. |
Tratamento de erros de integração (Produto B)
Erro | Mensagem | Solução |
Código do erro | Mensagem exibida | Ação a ser tomada para resolução do erro. |
Exemplo 2:
Quando uma mensagem é enviada do Logix para o Protheus, podem ocorrer situações em que o WebService não estará totalmente funcional. Nestes casos uma mensagem de erro genérica irá aparecer na tela:
Exemplo:
Erro ao enviar a mensagem de Cidade via Integração
Se o arquivo de log for analisado, poderemos ver a falha na comunicação com o sistema destino:
-------------------------------------------------------------------------------
WSCERR044 / Não foi possível POST : URL http://172.16.31.57:8011/ws/FWWSEAI.apw
ADVPL WSDL Client 1.080707 / tst on 20120315 08:49:51
-------------------------------------------------------------------------------
Para resolver este problema, verifique as configurações do sistema de destino, analisando o funcionamento do servidor utilizado para esta comunicação e a habilitação do endereço do WebService.
Checklist de suporte da aplicação
Crie um check-list de verificação de alguns pontos importantes para o funcionamento e atendimento da integração.
Instalação/Configuração
Relacione itens de verificação para garantir que a integração está corretamente instalada e configurada. Isto não pode ser uma cópia do procedimento de instalação/configuração, mas verificações pontuais que podem remeter aos itens da instalação.
Checklist de Verificações:
Relacione itens de verificações para que o atendente possa:
- Identificar o funcionamento da integração;
- Identificar a ocorrências de problemas;
- Coletar evidências do mau funcionamento relatado pelo cliente;
- Realizar possíveis ajustes na integração quanto à configuração ou negócio.
serie-docto | Série Documento |
cod-emitente | Código Emitente |
cod-observa | Código Observação |
cod-estabel | Código Estabelecimento |
it-codigo | Código Item |
nat-operacao | Natureza Operação |
numero-ordem | Ordem Compra |
num-pedido | Pedido Compra |
parcela | Parcela Ordem |
nr-ord-produ | Ordem Produção |
cod-refer | Referencia |
cod-depos | Deposito |
cod-localiz | Localização |
lote | Lote |
dt-vali-lote | Data Validade Lote |
cod-gr-forn | Grupo de Fornecedor |
ge-codigo | Grupo de Item |
fm-cod-com | Família Comercial |
icms-cst | CST de ICMS dos Itens |
cod-sit-trib-ipi | CST de IPI dos Itens |
aliq-cofins-cst | CST de Cofins dos Itens |
cnpj-destino | CNPJ de Destino |
cnpj-saida | CNPJ de Saída |
cod-estabel-ori | Código Estabelecimento de Origem |
desc-item | Descrição do Item |
dt-emissao | Data de Emissão |
icms-aliq | ICMS Alíquota |
mod-frete | Modalidade do Frete |
nro-docto | Numero do Documento |
reduc-bc | ICMS tag <pRedBC>": |
uf-end | Unidade de Federação do Emitente |
un-xml | Unidade de Medida do Item |
icms-csosn | Código da Situação de Operação no Simples Nacional de ICMS dos Itens |
Processos de Integração
Existem dois fluxos de integração: o recebimento de NF-e iniciado pelo ERP e recebimento de NF-e iniciado pelo Neogrid, os quais são descritos na sequência. Os diagramas de fluxo de dados apresentados na sequência detalham como ocorre a integração entre ERP, TSS (TOTVS Service SPED), Neogrid e Secretaria da Fazenda (SEFAZ). O primeiro Diagrama mostra o fluxo do recebimento iniciado pelo ERP.
Recebimento iniciado pelo ERP
O processo 1 indica o início da integração, onde o fornecedor envia o XML da NF-e para o seu cliente, que por sua vez, para utilização da recepção de NF-e deve salvar esse XML em um diretório específico (processo 2) para posteriormente ser enviado para validação. Quando o XML é enviado diretamente do fornecedor para o cliente é necessário que este seja validado (para garantir a integridade do arquivo e também sua situação na SEFAZ), a Neogrid é quem faz essa validação.
Para o envio de XMLs de NF-e para que sejam validadas (processo 3), o programa a ser utilizado é o “RE0517 – Importação de NF-e por diretório”, onde é informado o diretório da onde devem ser lidos os XMLs a serem enviados para validação. Caso necessário o programa pode configurado para execução em RPW. Neste processo os XMLs são enviados ao TSS, através do método “REMESSATOTVSCOLAB”. Através do retorno recebido do TSS, ou seja, se a notas foram ou não aceitas, são criadas mensagens no log: “Documento pendente para geração no recebimento (<chave do documento>)”, quando a nota foi aceita ou “Não foi possível criar o documento <chave do documento> no TSS" quando não foi aceita. Os XMLs importados através do RE0517 aparecem no Monitor do Conversor de NF-e (RE0708) com a situação “Em validação” e não poderão ser atualizados para o recebimento enquanto estiverem nesta situação. Caso alguma nota que está sendo importada possua CNPJ destino inválido (inexistente no ERP), não serão importadas para o conversor, ou seja, não aparecerão no conversor como “Em validação” e nem serão enviadas à Neogrid. Para este caso é apresentada uma mensagem no log indicando que o CNPJ destino é inexistente e o XML é movido para um subdiretório chamado “destino_inexistente”. Os demais XMLs que foram enviados para validação são movidos para um subdiretório chamado “lidos”.
Após os XMLs terem sido enviados para o TSS, os próximos passos são referentes ao envio para validação da Neogrid (processo 4 e 5). Após a Neogrid realizar a validação de integridade do arquivo, ela envia uma solicitação de consulta para a SEFAZ (processo 6), que realiza a consulta (processo 7) e disponibiliza o resultado para a Negrid. A Neogrid por sua vez, disponibiliza o XML validado para que o TSS possa buscá-lo e repassar para o ERP (processo 8).
O TOTVS Service Sped busca e armazena as NF-es validadas pela Neogrid (processo 9), e para que o ERP tenha conhecimento dessas NF-es é necessário que este fique frequentemente verificando se existem notas a serem buscadas no TSS. Para este processo, existe o programa “RE0516 – Busca de NF-e do TSS” que pode ser programado para executar em RPW, para que de tempos em tempos verifique se há NF-es para serem efetivadas no ERP. Este programa utiliza o método “MONITORTOTVSCOLAB” para recuperar as notas do TSS. Como a busca no TSS é feita com base na entidade (Estabelecimento) o usuário deve configurar neste programa os estabelecimentos dos quais deve-se buscar as NF-es.
Quando um documento buscado do TSS está com a situação “Documento Processado” é seguido o seguinte fluxo:
- Caso a nota exista no Conversor com o status “Em validação”, ou seja, foi enviada a partir do ERP (RE0516), então é executado o processo para enviar o documento “automaticamente” para o recebimento (se estiver parametrizado para isso). É atualizada a situação do documento para “Erro de negócio”, se não foi processada com sucesso e “Digitada Recebimento” caso tenha sido processado com sucesso.
- Caso a nota não exista no conversor, ou seja, veio diretamente pela Neogrid, então é executado o processo para criar o documento no conversor e processar “automaticamente” para o recebimento (se estiver parametrizado para isso). É atualizada a situação do documento para “Erro de negócio”, se não foi processada com sucesso e “Digitada Recebimento” caso tenha sido processado com sucesso.
Quando o documento buscado do TSS está com a situação “Documento rejeitado” então é criado um erro no log “52119 – Documento <chave do documento> rejeitado pela Neogrid”, e eliminado do monitor para que não fique “poluindo” a visualização, e se preciso, para que possa ser enviado novamente para o TSS/Neogrid.
(Processo 10).
Os documentos com erro ou processados com sucesso no recebimento, podem ser consultados através do “RE0708 – Monitor do Conversor de NF-e”, neste monitor é possível consultar a situação notas, corrigir possíveis erros e reprocessar as notas caso necessário.
Recebimento iniciado pelo Neogrid
No fluxo onde o recebimento da NF-e é iniciado pelo Neogrid, é praticamente igual ao primeiro, exceto pelo fato de que a NF-e é enviada diretamente para a Neogrid ao invés de para o cliente. O diagrama apresentado na sequência mostra esse processo.
Neste cenário, os arquivos de NF-e poderão ser recebidos pela NeoGrid por integração EDI ou Portal Web.
- Integração EDI: A solução NeoGrid permite que o recebimento dos arquivos das NF-es seja realizado com uma integração EDI. A equipe NeoGrid faz o contato com cada fornecedor, executando a instalação de um client NeoGrid ou implementando uma forma de comunicação utilizando protocolos de mercado como HTTP, FTP e WebService.
- Portal Web: A solução NeoGrid permite que o recebimento dos arquivos das NF-es seja realizado através de upload pelos fornecedores. A equipe NeoGrid fará o contato com cada fornecedor, executando a configuração da integração. O fornecedor é responsável por executar o upload manual na interface do Portal para cada NF-e autorizada ou cancelada.
Conceitos referentes a recepção de NF-e
- Entrada automática de NF-e de fornecedores
- FIFO na conversão de NF-e
- Natureza de operação por item
- Recepção de NF-e emitida em ambiente de homologação
Tratamento de erros de integração
Entrada automática de NF-e: A parametrização para entrada automática de NF-e para o recebimento é realizada por fornecedor e ocorre da seguinte forma:
Erro | Mensagem | Solução |
1878 | Documento já cadastrado! | O documento que está sendo importado já está no conversor de NF-e Entrada. - Verificar se a nota foi recebida através dos dois fluxos de integração (diretamente pela Neogrid) e está sendo importada manualmente, neste caso não é necessária a importação manual; - Verificar se a nota já foi importada anteriormente, ela pode estar “Em Validação” aguardando retorno da Neogrid. |
52116 | Estrutura do arquivo <nome-arquivo.xml> não corresponde a NF-e. | O arquivo XML que está que está sendo importado não possui o formato correspondente a uma NF-e, verificar porque o formato está incorreto e se o arquivo deve mesmo ser importado. |
17923 | Não existe Estabelecimento para CNPJ destino do documento <chave do documento> | Verificar se a NF-e que está sendo importada possui o destino correto (se foi direcionado para a empresa correta), pois o CNPJ destino da NF-e não está cadastrado no ERP. |
36370 | <Método de acesso ao TSS> Ocorreu erro na conexão com o WebService TSS! | Verificar se os serviços do TSS estão todos ativos, se não estiverem ativar. |
30639 | Não foi possível criar o documento <chave do documento> no TSS | Re-importar o arquivo para nova tentativa de envio ao TSS, se o erro persistir, entrar em contato com a equipe suporte para entender o que está ocorrendo. |
52016 | Função Bloqueio de item branco não permite gerar documento com item branco | Não foi possível efetivar a nota no recebimento, porque o Conversor está configurado para bloquear notas com item branco. - Se a nota realmente deve possuir o item branco, desmarcar o parâmetro, para que seja possível reprocessar a nota e efetivá-la no recebimento; - Caso o item não tenha sido sugerido corretamente, verificar as parametrizações (Engine de Regras, Cadastro Item X Fornecedor) para sugestão correta do item, ou efetuar a correção na tela de manutenção de documentos do conversor. |
52018 | Emitente não parametrizado para receber automaticamente o documento | Caso deseje que o fornecedor passe a receber as NF-es automaticamente, configurar no cadastrado de fornecedores, caso contrário, reprocessar a nota manualmente para o recebimento físico ou fiscal. |
52017 | Documento pendente para geração no recebimento | O documento está pendente de geração no recebimento, ou seja, aguardando a validação da NF-e pela Neogrid. Neste caso é necessário aguardar o retorno da validação para que a nota possa ser processada no recebimento. |
2049 | Natureza de operação em branco | Existe um bloqueio para entrada de documentos no físico quando não há natureza de operação informada, pois não há como saber que tipo de nota está entrando e se ela pode entrar ou não pelo recebimento físico. Obs.: A natureza de operação, que pelo XML é informada através da CFOP do item pode ser configurada através do engine de regras ou na tela de manutenção do item do documento no conversor. |
6189 | Emitente não pode ser desconhecido | O emitente da nota pode não ter sido sugerido corretamente, verificar as parametrizações (Engine de Regras, cadastro de fornecedor) para sugestão correta do emitente, ou efetuar a correção na tela de manutenção de documentos do conversor. |
2 | Não encontrado(a) Série para chave informada. | A série da nota pode não ter sido sugerida corretamente, verificar as parametrizações (Engine de Regras) para sugestão correta da série, ou efetuar a correção na tela de manutenção de documentos do conversor. |
52015 | Documento não possui relacionamento com nota de industrialização | Relacionar ao documento uma nota de industrialização através do botão “Relaciona”. |
52119 | Documento <chave do documento> rejeitado pela Neogrid | Verificar com a Neogrid o motivo da rejeição e a ação a ser tomada nesta situação. |
53694 | Documento <chave do documento> não importado, modelo é igual a 65 (NFC-e). | Não é possível importar documentos do tipo Nota fiscal eletrônica de venda ao consumidor final (NFC-e). O documento com chave de acesso <chave do documento> é do tipo NFC-e (modelo do documento é igual a 65). |
Nota:
- Podem ocorrer outros erros de negócio, no momento da efetivação da NF-e no recebimento físico ou fiscal, porém a solução a ser adotada é a mesma utilizada para o recebimento no produto (sem que seja o conversor).
Anexos