Italo Giurizzato Junior

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

Bom dia Diego, Comparando o XML de pedido de consulta, ele esta em conformidade com os Schemas. Sendo assim acredito que seja algum problema na SEFAZ. E tenho quase certeza que o problema é a palavra "NÃO" que aparece no conteúdo da tag <xServ>. A SEFAZ as vezes pisa na bola, vive recomendando que não devemos usar vogais acentuadas, cedilha, caracteres especiais, mas comete esse deslize de exigir na descrição do serviço uma palavra que cotem uma vogal com acento. A minha sugestão é que você entre em contato com a SEFAZ-RS pois é ela responsável por recepcionar todos MDF-e. Anexa os dois XML e questione eles sobre o motivo da rejeição.

Boa tarde Willian, Esta usando o programa exemplo do componente para realizar os testes?

Bom dia, Favor anexar o XML retornado pela consulta para que eu possa analisar.

Bom dia, Delete o seu arquivo WebISS.ini e atualize novamente os fontes, desta forma o Tortoise vai restaurar o arquivo WebISS.ini Os arquivos INI que eu utilizo são exatamente os mesmos que se encontram no repositório.

Bom dia, Qual é o provedor?

Bom dia Márcio, Favor verificar se as URLs de homologação e produção que você colocou no arquivo INI referente a cidade de Nova Xavantina estão corretas. Achei estranha pois não faz nenhuma referencia a cidade e sim ao provedor.