Italo Giurizzato Junior

Bom dia Gustavo, Até onde sei, o serviço que retorna os XML dos CT-e compactados é o DistribuicaoDFe. Mas o componente se encarrega de realizar automaticamente a descompactação e disponibilizar o conteúdo em uma propriedade chamada XML e se o componente estiver configurado para salvar em disco, o XML do CT-e descompactado será salvo.

Bom dia Walfrido, Pelo que entendi, quando você envia um lote contendo apenas 1 RPS não ocorre erro de Timeout, correto? O problema é quando você envia um lote contendo duas ou mais RPS, ai o erro de Timeout aparece, correto? Sendo assim, aumente o valor da propriedade Timeout do componente ACBrNFSe.

Bom dia, Eu não tenho muito conhecimento sobre a GNRe, mas estou achando que ao informar a UF GO em c01_UfFavorecida faz com que ele valide o c17_inscricaoEstadualEmitente como sendo de GO. O campo c17_inscricaoEstadualEmitente possui um numero com mais de 9 dígitos isso explica a mensagem de erro retornado.

Bom dia rapaziada, Depois de amanhã (01/11) é o nosso dia, vamos bebemorar com moderação.

No seu GNRE o que me chamou a atenção foi que o Destinatário é uma pessoa Física mas possui Insc. Estadual, esta correto?

Bom dia, Primeiramente obrigado pelo retorno. Me diz uma coisa a questão da URL de consulta do QR-Code o problema era na SEFAZ-SP? O valor do tipo de emissão esta sendo informado antes de Assinar o XML, correto? Depois de assinado e validado o XML não esta sendo alterado? Se com as outras UF esta funcionando, será que também não é um problema na SEFAZ-SP?

Bom dia Joffas, Já se encontra no repositório a sua contribuição, mais uma vez muito obrigado e desculpe pela demora em disponibilizar.

Pelo nome do arquivo noto que os seus fontes estão desatualizados. Nesse último teste notei que a rejeição foi outra, se refere a data de pagamento que tem que ser maior que a data atual.

Bom dia Walfrido, Com o programa exemplo também ocorre o mesmo erro? Qual é a configuração das propriedades SSLLib, ... SSLType?

Bom dia, Os arquivos *-env-lot.xml, *-env-lot-soap.xml, *-rec.xml e *-rec-soap.xml não são salvos?

Boa tarde a todos, O numero da serie só é mudada quanto o limite do numero da nota é atingido. E esse limite é 999.999.999 Se você não chegar até o final deverá informar a SEFAZ o porque não foi emitido as notas de numeração faltante. A SEFAZ espera receber 999.999.999 notas de cada serie, se pular a numeração você deverá inutilizar os números que não foram usados. Supondo que no final do ano a numeração chega a 900.000 para 999.999.999 são 999.099.999 números de notas que não serão mais enviadas da serie atual. Esses números deverão ser inutilizados. Como só podemos inutilizar uma faixa de 10.000 números sequenciais de cada vez o método Inutilizar deverá ser executado 99.910 vezes. Você acha isso correto? Imagina agora um supermercado com uma bateria de caixas composta por 30 PDVs. Se no final do ano mudar a série e iniciar uma nova contagem quanto tempo você acha que vai acabar as séries disponíveis? Apesar da serie ter 3 dígitos nos faz acreditar que vai de 001 até 999. Verdade, mas somente da 001 até 899 podemos usar para emitir as nossas notas, digamos normais, pois do 900 até 999 são de uso restrito. Se dividirmos 899 por 30 teremos 29,96 arredondando 30, ou seja daqui 30 anos as series se esgotariam. Você esta impondo um limite de vida de 30 anos para esse supermercado, isso é justo?

Na sua postagem só tem o *-gnre.xml e o *-pro-rec.xml

Eliezer, E funcionou sem nenhum problema?

Boa tarde, Você anexou o XML do GNRE do retorno após o envio e do Envio?

Configure o componente para salvar os arquivos de envio e de retorno. Configurações.Geral.Salvar := True; O arquivo *-env-lot.xml contem uma tag chamada <NumeroLote> que fica dentro do grupo <LoteRps>

Willian, Ao Consultar a Situação do Lote (lembrando que esse serviço só existe nos provedores que seguem a versão 1 do layout da ABRASF) temos como resposta: 1 - Lote não enviado 2 - Lote em processamento 3 - Lote processado com falhas 4 - Lote processado com sucesso A principio para fazer essa consulta devemos informar obrigatoriamente o numero do protocolo e opcionalmente o numero do lote que foi enviado. A minha sugestão é que o numero do lote seja sempre um numero sequencial controlado pela sua aplicação. Após o envio do lote é retornado o numero do protocolo, como dito anteriormente será utilizado para realizar a consulta a situação do lote.

Boa tarde, Essa alteração ao meu ver não faz sentido. Se a propriedade ConsultaLoteAposEnvio estiver com o valor True o que o componente vai fazer? 1. Se o provedor segue a versão 1 do layout da ABRASF será executado automaticamente a consulta a situação do lote: FConsSitLoteRPS.Executar; No executar dessa consulta já tem o Sleep. 2. Depois é executado o Consultar Lote: FConsLote.Executar; Que no seu executar não possui o Sleep, dai o motivo de ter. Conforme a sua alteração, atribuindo 40.000 a propriedade de configuração AguardarConsultaRet o que vai ocorrer? Se o provedor segue a versão 1 do layout da ABRASF e a propriedade ConsultaLoteAposEnvio estiver com o valor True, após o envio o componente vai ficar parado durante 80 segundos, 40 segundo do Sleep que você mudou de lugar, mais 40 segundos do Sleep que já existe no ConsSitLoteRPS como dito anteriormente. Por outro lado se o provedor segue a versão 2 do layout da ABRASF a parada será de apenas 40 segundo, uma vez que nessa versão não existe o Consultar Situação do Lote. Entendeu o motivo da posição do Sleep?

Boa tarde Chaves, Acrescentando o que o Felipe já lhe orientou, por se tratar de um provedor que segue a versão 2 do layout da ABRASF a principio você só vai ter que acrescentar esse provedor na unit pnfsConversao.pas criar um arquivo INI para ele, acrescentar a cidade no arquivo Cidades.ini, criar uma pasta Schemas junto com as demais e dentro desta pasta colocar os Schemas (arquivos XSD) usados por esse provedor. Como os provedores que seguem a ABRASF, tem o costume de mudar alguma coisa, talvez seja necessário alterar mais alguns unit do componente.

Adilson, O componente ACBrNFSe se utiliza de dois arquivos INI. Um é o Cidades.ini e o outro é do provedor, por exemplo: Virtual.ini Ao configurar o componente é informado o código IBGE da cidade. O componente procura no arquivo Cidades.ini a seção que tem esse código, desta forma ele encontra o provedor que atende essa cidade. Feito isso o componente carrega todas as informações do arquivo INI do provedor em questão para finalizar a sua configuração.

Boa tarde, Primeiramente não post como texto conteúdo de arquivos longo, procure sempre anexar. Segundo, o XML que você postou é do RPS e nem não contem a tag que se refere ao numero do lote. Muitos provedores não dão a importância para o numero do lote, por outro lado outros sim. Esse pelo jeito exige que o numero do lote seja sequencial.

Boa tarde Adilson, Como lhe disse segundo a versão 2 do layout da ABRASF esta previsto o serviço Substituir NFSe. Mas isso não garante que todos os provedores que seguem a versão 2 implementaram esse serviço em seus Webservices. A prova disso é o provedor TcheInfov2 (que segue a versão 2 e não implementou). Como você observou bem, por outro lado o provedor Virtual também segue a versão 2 e implementou. Basta olhar para a seção Substituir. No caso do TcheInfov2 o primeiro campo "Texto1" esta vazio não tem nada definido, por outro lado o Virtual tem toda a definição do Envelope do serviço que é composto por 10 linhas: Texto1 até Texto10. Aproveitando o Virtual veja esta seção: [ConsSit] IncluiEncodingCab=0 IncluiEncodingDados=0 Texto1= Podemos afirmar que esse provedor não implementou o serviço: Consultar Situação, concorda? Pois bem, é isso mesmo, alias na versão 2 do layout da ABRASF não esta previsto esse serviço, portanto é de se esperar que não esteja implementado.

Bom dia Kelly, Você utiliza o ACBrMonitor? Você chegou a comparar esses 2 arquivos INI que você anexou? Note que o S2299.ini contem uma seção chama dmDev e no outro não tem. Compare também nos dois arquivos os campos da seção ConsigFGTS.

Bom dia Eliezer, Não houve a necessidade de alterar mais nenhuma unit?

Bom dia Warley, Não tem nenhum fonte do referente ao componente do CT-e com uma bolinha vermelha no seu ícone? Se tiver, favor excluir, baixar novamente para restaurar o fonte original e reinstale tudo novamente. Favor habilitar a opção para apagar arquivos antigos.

Bom dia Edson, Essa empresa vende e realiza a entrega da mercadoria vendida com veiculo próprio e não "cobra" do cliente por este serviço? Se sim, no meu entendimento não existe a figura do contratante do serviço, portanto o grupo <infContratante> não deve ser preenchido. Com relação ao seguro, quem é que vai se responsabilizar por perdas ou danos? É o próprio emitente do MDF-e ou seja a empresa que vendeu a mercadoria e que esta realizando o transporte dela ou é o cliente que comprou a mercadoria? No meu entendimento o grupo <seg> deve constar no XML, por se tratar do modal Rodoviário, mas se o responsável pelo seguro é a Loja, neste caso o valor do campo <respseg> deve ser 1 - Emitente do MDF-e