Italo Giurizzato Junior

Bom dia Juliana, Primeiramente vamos ao Manual do CT-e versão 3.00 - páginas 225, 226. Nessas duas páginas temos uma relação de campos que não podem ser alterados através de uma CC-e - Carta de Correção. Se você emitiu um CT-e e depois emitiu uma carta de correção a SEFAZ entende que o transporte foi realizado e quem notou o erro foi o tomador do serviço. No mesmo manual - página 108, temos a regra M16 que diz: Vedado o cancelamento se possuir evento de Carta de Correção associado. Mesmo que o transporte não foi realizado, pela regra acima não tem como efetuar o cancelamento de um CT-e que possui uma Carta de Correção. E não existe nada para cancelar a carta de correção.

Olá Pessoal, Vejo muitos XML de CT-e que contem as informações sobre o Expedidor e o Recebedor. Quando devemos informa-los e em quais situações? Em um transporte de carga normal, ou seja, a transportadora pega a carga do Remetente e leva até o Destinatário não devemos informar o Expedidor e o Recebedor. O Expedidor e ou Recebedor só aparecem quando existe uma outra transportadora envolvida no transporte da carga e é essa transportadora que é informada como Expedidor ou como Recebedor. Vamos a um exemplo onde temos o transporte Normal, Redespacho e Redespacho Intermediário. Exemplo: Transportadoras envolvidas: A, B e C Remetente -> A -> B -> C -> Destinatário A transportadora A emite um CT-e Normal informando: Remetente: o remetente da mercadoria (quem vendeu) Destinatário: o destinatário da mercadoria (quem comprou) Recebedor: Transportadora B (o Recebedor foi informado pois a transportadora A não vai levar a carga até o Destinatário. o Expedidor não foi informado pois quem expediu a carga foi o Remetente que já esta informado) A transportadora B emite um CT-e de Redespacho Intermediário Remetente: o remetente da mercadoria (quem vendeu) - Opcional Destinatário: o destinatário da mercadoria (quem comprou) - Opcional Expedidor: Transportadora A (o Expedidor foi informado pois a carga não foi expedida pelo Remetente e sim pela Transportadora A) Recebedor: Transportadora C (o Recebedor foi informado pois a transportadora B não vai levar a carga até o Destinatário) A transportadora C emite um CT-e de Redespacho Remetente: o remetente da mercadoria (quem vendeu) Destinatário: o destinatário da mercadoria (quem comprou) Expedidor: Transportadora B (o Expedidor foi informado pois a carga não foi expedida pelo Remetente e sim pela Transportadora B. o Recebedor não foi informado pois quem vai receber a carga é o Destinatário que já esta informado) Note que a transportadora A pegou a carga do Remetente e levou até a transportadora B, esta por sua vez levou até a transportadora C, e esta por sua vez levou a carga até o destinatário.

Boa tarde Fábio, No momento estou atarefado ajudando do desenvolvimento das DLLs que vão ajudar em muito o pessoal que desenvolve em outras linguagens que não seja o Objeto Pascal. Esse pessoal hoje se utiliza o ACBrMonitor, mas gostariam muito se existisse uma DLL para cada componente. Quem sabe algum outro membro do fórum possa arregaçar as mangas e implementar. Eu no momento não tenho condições. Vou até colocar na minha lista de afazeres mas não sei lhe informar quando isso será possível de ser feito.

Boa tarde Joffas, Muito obrigado pela colaboração, assim que possível estaremos enviando para o repositório a atualização do programa exemplo.

Boa tarde ALA, O novo provedor é NFSeBrasil que já esta implementado. Favor abrir o arquivo Cidades.ini para saber como foi feito para outras cidades atendias pelo mesmo provedor.

Boa tarde, E qual seria a URL de consulta? A mesma URL do QR-Code?

Boa tarde, Abra a unit ACBrMDFeConfiguracoes e procure por GetPathEvento.

Boa tarde Diego, Esse erro de falha de Schema esta sendo retornado pela SEFAZ? Se sim, vamos lá. Os Schemas só são utilizados para validar o XML que vai ser enviado para SEFAZ, logo se não ocorreu erro de validação antes do envio não adianta você acessar o Portal e baixar os Schemas e atualizar. Quando é a SEFAZ que retorna esse erro, ou o problema é na SEFAZ ou alguma tag contem algum valor não aceito e a SEFAZ retorna um erro genérico como esse de erro de schema. Favor anexar o XML de pedido de consulta bem como o de retorno.

Bom dia Cordeiro, Já fiz a alteração no arquivo mencionado pelo BigWings, favor atualizar os fontes e iniciar os testes com o programa exemplo do componente. Caso ocorra problemas nos testes, favor anexar os arquivo soap de envio e de retorno para que possamos fazer os ajustes necessário, conforme o BigWings já tinha dito.

Bom dia, Ai que esta o problema, se após o envio ocorre um erro de comunicação não devemos enviar novamente, pelo simples fato de não sabermos se o erro ocorreu no envio ou no retorno. O procedimento correto é: Carregar o XML assinado do documento através do LoadFromFile, depois executar o método Consultar. Se o erro de comunicação foi no retorno com o procedimento acima o XML recebera o protocolo de autorização caso tenha sido autorizado é claro, bastando agora imprimir. Por outro lado se o erro ocorreu no envio, teremos como resposta a mensagem informando que o Documento não consta na base de dados da SEFAZ, ai sim podemos enviar novamente.

Boa tarde, Você concorda que se você resolver o problema de duplicidade por tabela resolve o outro? Pois bem, porque esta ocorrendo rejeição pode duplicidade? Essa rejeição só ocorre se o mesmo MDF-e for enviado mais de uma vez. Você não marca no banco de dados que o MDF-e já foi enviado e desta forma impedir que o usuário envie novamente? Você deixa o usuário alterar o numero do MDF-e que será enviado? O numero do MDF-e tem ser sequencial, a sua aplicação que tem que controlar e nunca deixar que o usuário possa alterar esse numero.

Bom dia, A NFS-e não funciona da mesma forma que a NF-e. Para começar na NFS-e, enviamos para o webservice o XML do RPS (Recibo Provisório de Serviço) e se tudo estiver OK, teremos como resposta o XML da NFS-e. Segundo, o numero do protocolo que retornado ao enviar o lote de RPS tem a mesma finalidade no numero do recibo quando enviamos um lote de NF-e para a SEFAZ. Ou seja, esse numero só diz a você que o lote foi recebido. O métodos ConsultarSituacao e ConsultarLoteRps se utilizam do numero do protocolo bem como do numero do lote. Detalhe importante se o provedor segue a versão 2 do layout da ABRASF devemos utilizar apenas o ConsultarLoteRps. O ConsultarSituacao só esta disponível nos provedores que seguem a versão 1 do layout da ABRASF e ele tem a finalidade de informar se o lote já foi processado ou não, se foi processado com sucesso ou com erros. Por outro lado o ConsultarLoteRps caso o(s) RPS forem processados com sucesso já temos no retorno o XML da(s) NFS-e, caso contrario teremos a lista de erros.

Deve ter alguma coisa errada, pois para mim funcionou. 1-env-lot.xml 1-rec.xml

Bom dia, Você esta lendo o valor do campo Status após obter o retorno da consulta, ou após carregar o XML da NFS-e? Você tem o retorno e ou o XML da NFS-e para que possamos analisar o problema? Se sim, favor anexar aqui.

Pessoal, A SEFAZ-CE na data de hoje (23/10/2018) esta com todos os serviços parados. O motivo é que criminosos na tentativa de um assalto a uma empresa de transporte de valores romperam os cabos de fibra ótica da SEFAZ. Vejam este link: http://diariodonordeste.verdesmares.com.br/editorias/seguranca/online/policia-federal-frustra-assalto-a-empresa-transportadora-de-valores-na-capital-1.2016644

Bom dia Jeferson, Ao aparecer o erro de nó não encontrado clique no botão Continuar.

Bom dia, Tente com essa configuração: AACBrNFSe.Configuracoes.Geral.SSLLib := libWinCrypt; AACBrNFSe.Configuracoes.Geral.SSLCryptLib := cryWinCrypt; AACBrNFSe.Configuracoes.Geral.SSLHttpLib := httpWinHttp; AACBrNFSe.Configuracoes.Geral.SSLXmlSignLib := xsXmlLib2; e o SSLType atribua o valor LT_TLSv1_2

Boa tarde Igor, Neste caso, você deve fazer a alteração no arquivo Cidades.ini, informando o provedor correto e depois se necessário for alterar o arquivo INI do provedor incluindo as URLs de produção e homologação que constem no manual ou no site da prefeitura. Por fim iniciar os testes. Estando tudo funcionando, favor anexar os arquivos INI alterados para que possamos enviar para o repositório.

Boa tarde Alex, Muito obrigado pela colaboração, já enviei para o repositório.

Bom dia Adilson, Como dito anteriormente esse serviço não esta previsto na versão 1 do layout da ABRASF. Mas na versão 2 esta previsto sim. Veja bem, estar previsto é uma coisa o provedor ter implementado em seu webservice é outra. Tenho um relação que dos provedores que seguem a versão 1 e os que seguem a versão 2, bem como aqueles que não seguem o layout da ABRASF. Você pode montar a sua, basta abrir o arquivo INI de cada provedor e olhar para o campo Layout, ele tem a informação que você deseja. Mas é bom checar também no mesmo arquivo INI a montagem dos Envelopes, para ver se foi montado para o Substituição, veja este exemplo abaixo: Provedor TcheInfov2 Layout=ABRASFv2 Segue a versão 2 do layout da ABRASF. Montagem do Envelope para o Substituição: [Substituir] IncluiEncodingCab=0 IncluiEncodingDados=0 Texto1= Como você pode ver esse provedor apesar de seguir a versão 2 do layout da ABRASF e seu webservice não implementou o serviço Substituir NFS-e.

Bom dia Gislaine, Primeiramente em um MDF-e só pode constar CT-e ou NF-e, jamais ambos os documentos. Segundo o manual do MDF-e versão 3.00 na página 106 o grupo <infNFe> pode se repetir 4.000 vezes, ou seja, podemos relacionar até 4.000 NF-e em um único MDF-e. Na página 103 temos o grupo <infCTe> que também pode se repetir 4.000 vezes. Portanto a quantidade máxima de CT-e ou NF-e em um único MDF-e é de 4.000

Bom dia Jeferson, Vamos fazer o seguinte. Abra o arquivo Cidades.ini e inclua a cidade em questão nos mesmos moldes que outras que se utilizam do mesmo provedor. Depois abra o arquivo GovBr.ini e inclua a URL de produção e de homologação para a respectiva cidade da mesma forma que foi incluída para as demais cidades. Por fim, usando o programa exemplo inicie os testes. Funcionando, ou seja, conseguindo enviar, consultar e cancelar, favor anexar os arquivos Cidades.ini e GovBr.ini para que possamos analisar e estando tudo OK enviaremos para o repositório.

Bom dia Tathiana, Você copiou para maquina do cliente as DLLs usadas pelo ACBr? Esta usando o Capicom? Se sim, além de copiar a DLL realizou o seu registro?

Bom dia Igor, Para isso existe uma opção chamada Editar, que fica logo abaixo da sua postagem. Vamos ao que interessa. Já procurou pela respectiva cidade no arquivo Cidades.ini? Pelo jeito não, pois se tivesse procurado iria encontrar e saberia qual é o provedor. Você sabe também que existe um programa exemplo do componente ACBrNFSe, que através dele podemos realizar testes de emissão de NFS-e para uma determinada cidade, desde que ela já se encontra no arquivo Cidades.ini Se não sabe agora ficou sabendo. Vamos você tem a força, use o programa exemplo para realizar os testes.

Bom dia a todos, Sergio, essa unit não faz parte do componente ACBrReinf. Daniel, muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.