Italo Giurizzato Junior

Boa tarde Augusto,
Estanho, o código de verificação  é uma string, e ao meu ver o tipo de alinhamento não era para causar esse problema.
Muito obrigado pela colaboração, já esta no repositório.
 

Boa tarde Giovani,
O seu código deve ficar da seguinte forma:
infRespTec.CNPJ := CNPJ da empresa de software infRespTec.xContato := meu nome infRespTec.email := meu email infRespTec.fone := meu telefone Lembre-se configurar o componente é uma coisa, alimentar com os dados da venda é outra.
As 4 linhas acimas devem ser incluídas na rotina que alimenta o componente.
Já as linhas abaixo devem ser incluídas na rotina que configura o componente.
// Enquanto o desenvolvedor não tiver o seu CSRT deverá configurar // as propriedades IdCSRT e CSRT conforme exemplo abaixo. ACBrNFe1.Configuracoes.RespTec.IdCSRT := 0; ACBrNFe1.Configuracoes.RespTec.CSRT := '';  

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

Bom dia,
Quando uma nota é enviada e ocorre algum erro, a primeira providencia a ser tomada é realizar uma consulta, pois não sabemos se o erro ocorreu no envio ou no retorno da SEFAZ.
Se o erro ocorreu no retorno, a consulta vai nos informar o resultado do processamento, se a nota estava correta, será retornado o protocolo de autorização.
É interessante ao realizar essa consulta, estarmos com o XML da nota carregado no componente, pois se for retornado o protocolo de autorização o XML será atualizado automaticamente, com isso podemos imprimir o DANFE.
Por outro lado se o erro ocorreu no envio, a consulta vai nos retornar que a nota não consta na base de dados.
O que fazer neste caso?
Podemos tentar novamente o envio ou inutilizar o numero da nota cujo envio não ocorreu por falha na SEFAZ e por fim enviar a nota pelo SAT (contingência da NFC-e) no Estado de São Paulo.

Matias,
As linhas abaixo não vejo necessidade.
dtmManifestoEletronico.ACBrMDFe.Manifestos.GravarXML(vArquivo);
dtmManifestoEletronico.ACBrMDFe.WebServices.Recibo.Executar; 
Pois a primeira linha (...Assinar;) se encarrega de gerar,  assinar o XML e salvar em disco.
A linha (...Consultar;)  também não vejo necessidade, pois o enviar realiza todo o processo e caso o MDF-e seja autorizado o XML será atualizado com o protocolo de autorização.

Bom dia,
A principio não vejo motivo para a rejeição, mas notei que as informações (valores) foram passados a fim de testes e que não condiz com a realidade, pois tem todos os tipos de deduções e descontos.
O que me chamou a atenção é que nas informações do item não foi informado quantidade e nem valores.
Talvez, a SEFAZ esteja rejeitando a nota por esse motivo, mas infelizmente esta apresentando uma outra rejeição que não tem nada haver.

Bom dia Rodrigo,
Desfaça a sua alteração e leia esse tópico:
 

Bom dia Paulo,
Muito obrigado pela colaboração, já enviei para o repositório.

Bom dia Jamil,
As notas que não foram autorizadas pela SEFAZ (33190300127817000125550090000002961000002967-nfe.xml e nfe2.xml) contem no grupo <retirada> e ou <entrega> os novos campos: cPais e xPais.
Já a nota 33190300127817000125550070000117531000117530-nfe.xml que foi autorizada pela SEFAZ não contem esses campos dentro do grupo entrega.
Essas 3 notas foram enviadas para o ambiente de Produção.
Pelo que notei, você utiliza o ACBrMonitor, correto?
Pois bem, o ACBrMonitor se utiliza de uma rotina para ler o arquivo INI para gerar o XML, essa rotina tenta ler os campos cPais e xPais do arquivo INI, se esses campos não existem ele assume valores padrões.
A minha sugestão é você acrescentar esses dois campos da seguinte forma:
[Entrega]
CNPJCPF=61924742004195
xLgr=RUA BRAS CUBAS
nro=SN   
xCpl=LT 01 QD 29         
xBairro=OLAVO BILAC         
cMun=3301702
xMun=DUQUE DE CAXIAS
cPais=0
xPais=
Acredito que desta forma ele não vai usar os valores padrões e com os valores passados, ou seja, zero para o código do pais e "string vazia" para o nome (xPais) os campos não vão ser gerados no XML e consequentemente a nota será autorizada na SEFAZ.

Bom dia Idez,
Por favor leia esse tópico:
 

Paulo,
NotaBlu e SP estão usando a mesma unit para gerar o XML sendo assim acredito que poderíamos contornar o problema da seguinte forma:
if (FProvedor = proSP) and (NFSe.TipoTributacaoRPS <> ttTribnoMun) then Gerador.wCampoNFSe(tcStr, '', 'MunicipioPrestacao', 1, 7, 0, NFSe.Servico.CodigoMunicipio, ''); Incluindo uma condição para checar o provedor.

Bom dia,
Para que uma empresa possa ter acesso aos XMLs de CT-e onde o CNPJ dessa empresa figura como: Remetente ou Destinatário, ou Recebedor ou Expedidor ou Tomador ou se encontra na lista de autorizados (grupo <autXML>) basta usar o método DistribuicaoDFePorUltNSU implementado no componente ACBrCTe.
A cada execução desse método devemos informar como sendo o Ultimo NSU o numero retornado no campo ultNSU da execução anterior.
Se isso já esta sendo feito e mesmo assim alguns XMLs não são baixados, algo esta errado na SEFAZ.
Infelizmente existem Aplicações que geram o XML do CT-e de forma errada, acabam informando como Expedidor os mesmos dados do Remetente e o Recebedor os mesmos dados do Destinatário.
O Expedidor não é o Remetente e nem o Recebedor é o Destinatário.
O Remetente é quem esta enviando a mercadoria (vendedor por exemplo).
O Destinatário é quem vai ficar com a mercadoria, pois comprou para usar ou para revender.
O Expedidor é a transportadora que esta despachando a mercadoria para uma outra transportadora para que esta possa dar continuidade ao transporte da mercadoria.
O Recebedor é a transportadora que esta recebendo a mercadoria de uma outra transportadora para que possa dar continuidade ao transporte da mercadoria.
Exemplificando:
Remetente  --> Transportadora  --> Destinatário
ou
Remetente  --> Transportadora "A" (Expedidor)  --> Transportadora "B" (Recebedor)  --> Destinatário
ou
Remetente  --> Transportadora "A" (Expedidor)  --> Transportadora "B"  --> Transportadora "C" (Recebedor)  --> Destinatário
Nesse ultimo exemplo a Transportadora "B" para a Transportadora "A" ela é o Recebedor, mas para a Transportadora "C" ela é o Expedidor.
 
Se o seu cliente é o Tomador do Serviço não importa se ele é o Remetente ou o Destinatário da mercadoria, a transportadora tem como obrigação legal de disponibilizar o XML do CT-e.
É preciso ter em mãos um XML onde o seu cliente figura como Remetente e tomador (pois foi isso que entendi na sua postagem) para ver se ele não esta aparecendo também como Expedidor.
E um outro XML onde ele figura como Destinatário (tomador ou não) para ver se ele aparece também como Recebedor.
Os XML que ele não consegue baixar é de uma transportadora diferente dos XMLs que ele consegue baixar?
 

Boa tarde Davila,
O provedor Sigep já esta implementado no componente.
Para enviar para o webservice de produção use o método EnviarSincrono, para cancelar use o método Cancelar e para consultar use o método ConsultarNFePorRps.
Como o provedor não tem um webservice de homologação, você pode usar o método GerarLote, esse método gera um lote de RPS e salva em disco, dessa forma você pode pegar esse arquivo para usar para validação no site do provedor.

Boa tarde,
Em vez de:
CST=1
tente:
CST=01
No caso do PIS e COFINS

Davidson,
Se o XML da nota foi gerado, assinado, validado e enviado pelo Monitor, mas foi rejeitada pela SEFAZ com o argumento: Falha de Schema a explicação é muito simples:
O webservice não esta preparado ainda para processar o XML com as novas tags ou grupos.
Como você esta enviando para o ambiente de homologação e esta ocorrendo esse erro, podemos concluir que a SEFAZ-MG não fez o dever de casa, pois desde do dia 25/02/2019 era para estar pronto essa implementação no ambiente de homologação.
Será que dentro de 1 mês e meio vão conseguir implementar no ambiente de homologação e de produção?
Pois o prazo é para liberar no dia 29/04/2019 o ambiente de produção.
 

Boa tarde Valdir,
Só existe dois tipos de consulta:
Pelo numero do Recibo que é retornado assim que a nota é enviada e pela Chave.
Portanto não existe uma consulta pelo numero do Protocolo.
Não devemos confundir o numero do Recibo com o numero do Protocolo.
Como dito acima o numero do Recibo é retornado pela SEFAZ assim que ela recebe o lote de notas, logo temos um Recibo atrelado ao lote inteiro independente da quantidade de notas contidas nesse lote.
Já o numero do Protocolo só é retornado após o processamento do Lote, ou melhor, ao realizar uma consulta pelo numero Recibo teremos o resultado do processamento, o Protocolo é atrelado a nota, portanto se for enviado um lote com 30 notas, a SEFAZ vai retornar um numero de protocolo para cada nota que por ventura foi autorizada.
As notas rejeitadas não são armazenadas no banco de dados da SEFAZ e portanto não tem numero de protocolo.
Agora você precisa analisar a sua rotina para descobrir se ela não esta salvando no banco de dados da sua aplicação o protocolo de uma nota autorizada em uma outra que não foi.
Uma observação importante:
Quando enviamos um lote de NF-e, mesmo que esse lote tenha apenas uma nota, a SEFAZ sempre vai retornar o numero do recibo.
Por outro lado quando enviarmos um lote de NFC-e no modo síncrono (somente uma nota), a SEFAZ demora um pouco mais para responder, pois nesse modo ela já processa as informações da nota e retorna o protocolo de autorização caso esteja tudo OK, caso contrario a nota é rejeitada.
É uma ou outra SEFAZ que retorna o numero do recibo também.
Agora se enviarmos um lote com duas ou mais NFC-e, o envio é assíncrono, neste caso o funcionamento é o mesmo da NF-e, ou seja, a SEFAZ retorna o recibo, de posse dele devemos fazer a consulta para obter o resultado do processamento das notas.
 

Bom dia,
Favor trocar os schemas.
Você esta usando os schemas que devemos usar para o ambiente de produção.
Verifique se dentro da pasta dos schemas tem um schema chamado: leiauteNFe_v4.00_Homologacao ?
Se sim, ele deve ser renomeado para: leiauteNFe_v4.00

Charles,
Esta ocorrendo erro de validação ou rejeição por parte da SEFAZ?
Se esta ocorrendo erro de validação é porque você esta usando o schema destinado ao ambiente de produção, neste caso é preciso trocar.
Note que na pasta: ...\Exemplos\ACBrDFe\Schemas\NFe temos dois XSD: leiauteNFe_v4.00, sendo que um deles tem a palavra Homologação no nome.
Devemos renomear para poder fazer os testes em homologação.
Por outro lado se é rejeição da SEFAZ, então isso significa que a mesma não fez a tarefa de casa, pois a sua nota esta para ambiente de homologação e deveria ser aceita.

Bom dia Dércio,
Esta usando o arquivo INI do provedor que esta na pasta: ...\Exemplos\ACBrDFe\ACBrNFSe\ArqINI ?

Boa tarde Samuel,
Favor atualizar os fontes, reinstale os componentes.
Note que fiz uma alteração no arquivo INI do provedor WebISSv2 e em fez de incluir o provedor na lista, coloquei o Sleep, mas que pode ser configurado através da propriedade: AguardarConsultaRet.

Boa tarde Dércio,
Essa tag é nova e obrigatória, como você deve estar fazendo testes, ou seja, configurou o componente para o ambiente de homologação o componente gera automaticamente essa tag.
O motivo de gerar automaticamente é porque o ambiente de homologação espera por essa tag.
Com relação ao erro de validação é porque você esta usando o schema para o ambiente de produção que só a partir de 29/04/2019 vai passar a exigir essa tag.
Na pasta ...\Exemplos\ACBrDFe\Schemas\NFe note que existe os seguintes XSD:
leiauteNFe_v4.00.xsd ====> que deve ser utilizado em ambiente de produção até o dia 29/04/2019
e
leiauteNFe_v4.00_Homologacao.xsd ====> que deve ser renomeado para leiauteNFe_v4.00.xsd e utilizado em ambiente de homologação e em produção a partir de 29/04/2019
 

Bom dia,
Primeiramente o Cancelamento Por Substituição nessa primeira etapa só esta disponível para a NFC-e, logo não podemos enviar esse tipo de evento para a NF-e.
Quanto ao retorno da consulta de uma NFC-e não existir o procEventoNFe de uma nota cancelada por substituição pode ser que a SEFAZ ainda esteja fazendo os ajustes necessários para que ele seja gerado.
Lembre-se que o Cancelamento Por Substituição é um evento novo.

Bom dia Rafael,
Fiz mais uma alteração, vamos ver se agora vai funcionar a contento.

Bom dia Edmar,
Muito obrigado pela correção, já enviei para o repositório.

Boa tarde,
Não tenho nada em relação ao SPED, mas se neste devemos informar também as notas canceladas, então lança a nota 20 como cancelada e a 21 como autorizada.
Eu penso da seguinte forma: quem tem 1 não tem nada, quem tem 2 tem 1.
Se o seu cliente tem um volume muito grande de vendas eu sugiro que ele tenha 2 conexões de internet com provedores diferentes.
Se um deles vier a falhar, ou seja, ficar inativo, por problemas técnicos ou rompimento de cabo, tem o outro.
Uma outra saída é a conexão 3G, 4G que apesar de lerda mas pode resolver esse problema.