Italo Giurizzato Junior

Boa tarde Rigotti, Infelizmente conversar com o pessoal da prefeitura sobre esses assuntos é falar com a porta, não entendem de nada. O certo mesmo, é conversar com o pessoal do provedor, neste caso o Thema. Questiona-los sobre a atualização dos Schemas para atender a cidade de Passo Fundo no que diz respeito as novas Naturezas de Operação.

Bom dia osocran, Carregue o XML do CT-e através do LoadFromFile, depois pegue o numero do protocolo da seguinte forma: sProtocolo := ACBrCTe.Conhecimentos.Items[0].CTe.procCTe.nProt;

Bom dia Cesar, Desculpe, só vi agora, vou analisar e fazer as devidas alterações. Ainda hoje estarei disponibilizando. Já fiz as devidas alterações, por favor atualize os fontes e teste novamente.

Bom dia Leonardo, Muito obrigado pela colaboração, ainda hoje estarei disponibilizando.

Bom dia Luis, Você esta tentando enviar um CT-e em Homologação incluindo como documento originário a chave de uma NF-e, correto? E o CT-e é rejeitado, pelo simples fato da NF-e não constar na base de dados do ambiente de homologação. Mude. Informe como documento originários: Outros (outro tipo de documento) por exemplo uma declaração. Desta forma vai funcionar e você vai conseguir realizar todos os testes necessários.

José, A questão é bem simples, quem vai validar a carta de correção é um Software e não um ser humano. Baixe e imprime (4 folhas) a Nota Técnica 2014/001 que trata de Regras de Validação. Página 2, Item 5 temos a seguinte regra: Verificar se a tag informada em campoAlterado existe no layout e se pertence ao grupoAlterado indicado na carta de correção. Esse é uma regra que será implementada pela SEFAZ, caso o campo ou grupo não pertencer a estrutura do XML a CC-e será rejeitada com o código 525. Portanto volto a frisar que devemos informar o nome da TAG tanto para o grupoAlterado quanto para o campoAlterado ao alimentar o componente para enviar uma CC-e do CT-e. Veja também o item 9 da página 4 da mesma NT.

Bom dia José, Tem que ser conforme o exemplo 2, ou seja, informar o nome da TAG e não a descrição da mesma.

Cesar, Como não tenho um cerificado valido para realizar testes, lhe peço que faça o seguinte: informe a URL abaixo no navegador para que possamos ter a estrutura do SOAP de envio e de retorno. https://hnfe.sefaz.ba.gov.br/webservices/NfeConsulta/NfeConsulta.asmx Talvez seja necessário informar no final da URL o seguinte texto: ?wsdl Cole os dois SOAP em um bloco de notas e post como anexo.

Bom dia Ailton, Favor atualizar os fontes e tentar novamente.

Bom dia, A consulta serve para você obter a situação atual de um documento previamente enviado para SEFAZ. Se você carregar o componente com o XML do MDF-e que esta assinado, foi enviado para SEFAZ, mas por algum motivo ficou sem o protocolo de autorização. Ao executar em seguida a consulta, o componente alem de realizar a consulta e salvar o seu retorno, se encarrega de atualizar o XML, deixando-o assinado e protocolado, caso no retorno contenha o protocolo de autorização.

Bom dia Alex, A quanto tempo faz que você não atualiza os fontes? Faz tempo? Então, desinstale os componentes do Delphi, apague tudo sobre o ACBr e baixe tudo novamente e instale.

Rodrigo, A diferença é que a SEFAZ hoje só aceita MDF-e na versão 1.00a. Quando é lançado uma nova versão é comum a SEFAZ aceitar as duas versões por um certo período, depois você é obrigado a utilizar somente a versão mais atual. No caso do MDF-e a versão atual é a 1.00a. Atenção, estou me referindo a versão da estrutura do XML, se você abrir o XML usando um navegador vai notar que nele aparece 1.00 como sendo a versão.

Bom dia Rodrigo, O protocolo é o de autorização, ou seja, ao emitir o MDF-e a SEFAZ retorna o protocolo de autorização, portanto é esse numero a ser utilizado ao efetuar o encerramento. Um MDF-e só será encerrado uma unica vez, se você tem vários descarregamentos dentro da mesma UF, pela lógica seria o último.

Bom dia Rodrigo, Você esta adicionando uma das informações: CNPJForn, CNPJPg e nCompra ? Se sim, lembre-se que: CNPJForn e nCompra são obrigatórios, CNPJPg é opcional. Se você não adicionar nenhuma das três informações o grupo <disp> não será gerado e consequentemente o grupo <valePed> também não. Desta forma o seu MDF-e vai ser validado.

Bom dia Emílio, O que o seu cliente esta fazendo esta completamente errado, não existe isso de emitir um CT-e no final do mês. Na verdade ele quer economizar e vai se dar muito mau, a economia em papel não vai significar nada em relação a multa que ele vai levar. Como que ele transporta um carga se utilizando apenas da NF-e do remetente, não pode, a carga não é dele é de terceiro, ele tem que emitir o CT-e. E complementando o que a Graça escreveu, um CT-e Globalizado é quando tenho apenas um tomador, não importa se é o remetente ou o destinatário. Mas o CT-e tem que ser emitido para acobertar a carga a ser transportada. Repito deixar para emitir no final do mês esta completamente errado. O CT-e tem que ser emitido antes do serviço ser realizado e não depois. Outra coisa, uma transportadora que em vez de informar a chave da NF-e como documento originário, informa como outros, esta abrindo uma brecha para que o emitente da NF-e possa efetuar o cancelamento da mesma. O remetente emite a NF-e; A transportadora emite o CT-e e não informa a chave da NF-e; O transporte é realizado; O destinatário recebe a mercadoria e não se manifesta (Manifestação do Destinatário); O remetente cancela a NF-e. Como a transportadora não informou a chave da NF-e e o destinatário não se manifestou, o remente aproveita e cancela. Você percebeu o tamanho da encrenca?

Bom dia André, Se esta ocorrendo Violação de acesso na validação, verifique se o componente esta configurado corretamente quanto ao PathSchemas e verifique também se todos os schemas da versão 2.00 estão presentes na pasta.

Bom dia Cesar, Estamos chegando lá. Vamos a mais um teste. Por favor, temos uma linha que salva o arquivo de retorno, faça a seguinte alteração, para que possamos visualizar o retorno por completo. Esta dessa form: if FConfiguracoes.Geral.Salvar then begin FPathArqResp := FNFeChave+'-sit.xml'; FConfiguracoes.Geral.Save(FPathArqResp, FRetWS); end; altere para: if FConfiguracoes.Geral.Salvar then begin FPathArqResp := FNFeChave+'-sit.xml'; FConfiguracoes.Geral.Save(FPathArqResp, FRetornoWS); end; Essa alteração é na unit ACBrNFeWebServices.pas Post como anexo o arquivo <chave>-sit.xml

Boa noite Cesar, Favor atualizar mais uma vez e testar novamente.

Boa tarde, O componente a principio gera o XML, assina e valida. Após envia-lo para SEFAZ se o mesmo for autorizado, é retornado o protocolo de autorização. O componente se encarrega de atualizar o XML, deixando-o completo, ou seja, assinado e protocolado. Atenção estou supondo que você esta utilizando o comando Enviar(<numlote>).

Boa tarde Graça, Uma coisa que achei estranho logo de inicio foi o código do tipo do evento: 110140 para a NF-e sendo que para o CT-e é 110113. Por que achei estranho, pois até agora os eventos que são comuns em ambos os documentos o código é igual. Bom, o jeito agora seria fazer o componente gerar o EPEC para NF-e utilizando-se do código 110113 e ver o retorno da SEFAZ. O que eu estou achando: 1. Erraram ao montar o Schema. 2. A SEFAZ esqueceu de criar no Web Service o tipo 110140 ou erraram mais uma vez só que agora na Nota Técnica.

Boa tarde Cesar, Por favor atualize os fontes e tente novamente.

Boa tarde Ailton, Em quais partes estão ocorrendo erros?

Boa tarde Graça, Acredito ter encontrado o problema. Segundo a NT 2014/001 página 6 fica claro que as TAGs: vNF, vICMS e vST são filhas de P17 que é o grupo detEvento. Note que pela mensagem de erro do validador diz que o elemento dest esta incompleto, esta faltando o vNF. Muito bem, vamos então checar o Schema: e110140-v1.00 que se refere ao EPEC. Notei que as TAGs: vNF, vICMS e vST estão definidas dentro do elemento dest e não fora como consta na Nota Técnica. Bom, ou a NT esta errada ou é o Schema. O que pode ser feito, alterar a unit pcnEnvEventoNFe, modendo as linhas que geram as TAGs mencionadas acima para dentro do grupo dest. Desta for vai passar pela validação. Se a SEFAZ rejeitar o EPEC, significa que o Schema esta errado. Como alterar a unit: Conforme o manual esta desta forma: Gerador.wGrupo('/dest'); Gerador.wCampo(tcDe2, 'P32', 'vNF', 01, 15, 1, Evento.Items.InfEvento.detEvento.vNF, DSC_VNF); Gerador.wCampo(tcDe2, 'P33', 'vICMS', 01, 15, 1, Evento.Items.InfEvento.detEvento.vICMS, DSC_VICMS); Gerador.wCampo(tcDe2, 'P34', 'vST', 01, 15, 1, Evento.Items.InfEvento.detEvento.vST, DSC_VST); Segundo o Schema seria: Gerador.wCampo(tcDe2, 'P32', 'vNF', 01, 15, 1, Evento.Items.InfEvento.detEvento.vNF, DSC_VNF); Gerador.wCampo(tcDe2, 'P33', 'vICMS', 01, 15, 1, Evento.Items.InfEvento.detEvento.vICMS, DSC_VICMS); Gerador.wCampo(tcDe2, 'P34', 'vST', 01, 15, 1, Evento.Items.InfEvento.detEvento.vST, DSC_VST); Gerador.wGrupo('/dest');

Boa tarde Marcos, Só ocorre erro na linha: ACBrNFe1.Configuracoes.WebServices.UF:= Banco.QryPrincEmpresa.FieldByName('ESTADO').AsString; Caso o valor atribuído a UF seja inválido, ou seja, não é uma sigla de um Estado brasileiro ou o valor é vazio.

Boa tarde, Revendo o seu post #3, temos: Estou fazendo assim ACBrMDFe1.WebServices.Recibo.Recibo := NrRecibo; ACBrMDFe1.WebServices.Recibo.Executar; sStatus := IntToStr(ACBrMDFe1.WebServices.Retorno.MDFeRetorno.ProtMDFe.Items[0].cStat); Esta errado o que você fez, pois se você esta executando o WebServices.Recibo.Executar, não podemos pegar o statuso de WebServices.Retorno e sim do WebServices.Recibo