Italo Giurizzato Junior

Boa tarde Brito, No programa exemplo tem um campo que você ativa para salvar os arquivos Soap. Faça isso, repita os testes e anexa os arquivos "*-soap.xml"

Boa tarde, Fiz diversos ajustes nos fones e nos arquivos INI com o objetivo de fazer funcionar o provedor GeisWeb. Favor atualizar os fontes e iniciar os testes usando o programa exemplo.

Boa tarde Diego, Já esta no repositório.

Boa tarde Camilo, Essa nota de numero 5 não foi enviada para a SEFAZ através de outro programa, por exemplo o programa gratuito do SEBRAE? Pois analisando o Log que inicia em 10/06/2020 a tentativa envio da nota de numero deu inicio no dia 21/10/2020 já com a rejeição de duplicidade com diferença de chave. Notei que toda vez que você pede para gerar a chave é informado um código de nota diferente. Veja: 21/10/2020 16:04:50 - NFE.Gerarchave(15,51230217,55,1,5,1,"21/10/2020","19152664000102") 21/10/2020 16:04:50 - OK: 15201019152664000102550010000000051512302170 21/10/2020 16:09:40 - NFE.Gerarchave(15,39166664,55,1,5,1,"21/10/2020","19152664000102") 21/10/2020 16:09:40 - OK: 15201019152664000102550010000000051391666649 Assim fica complicado. A sua aplicação tem que gerar o código aleatório para a nota e salvar no banco de dados e sempre utilizar o mesmo código.

Heptas, Já alterei o arquivo Cidades.ini e enviei para o repositório. Muito obrigado pela colaboração. Não se faz necessário alterar o fonte do componente.

Realmente tem a tag, não encontrei mais nada que pudesse gerar esse erro.

Boa tarde, Essas alterações foram feitas na rotina que alimenta o componente com os dados da nota, correto? E o arquivo Cidades.ini como que ficou? Anexa ele aqui.

Boa tarde Claudio, Não sei se interfere ou não, mas o seu XML não contem a tag <RegimeEspecialTributacao>

Bom dia, Você vai ter que fazer esses ajustes e enviar novamente até o RPS seja processado com sucesso e o XML da NFS-e seja gerado pelo webservice.

Bom dia Claudio, Fazendo testes com a cidade Oriximiná/PA que se utiliza do mesmo provedor o retorno que eu tenho ao enviar o RPS é: Inicio TNFSeEnviarLoteRPS Método..... : Enviar Lote Código Erro : E157 Mensagem... : Usuario nao esta autorizado a utilizar esse servico para esse contribuinte. Correção... : Solicite ao contribuinte autorizacao para utilizar o servico em seu nome. Provedor... : ISSNet Já com a cidade de Cuiabá: Inicio TNFSeEnviarLoteRPS Método..... : Enviar Lote Código Erro : soap:Server Mensagem... : O servidor nao pode processar a solicitacao. --->Referencia de objeto nao definida para uma instancia de um objeto. Correção... : Provedor... : ISSNet Logo não tive esse erro 500. Anexa o XML de envio do lote para que eu possa analisar.

Camilo, No log do ACBr Monitor não consta o envio da primeira vez dessa nota de numero 5?

Camilo, Além de desativar a opção que eu recomendei, como é gerado o código da nota? Esse código esta salvo no banco de dados? Você não tem um cópia do primeiro arquivo TXT dessa nota? Não conheço nenhum recurso para recuperar pelo menos a chave.

Bom dia Camilo, Quanto você enviou a nota cuja chave é: 15201019152664000102550010000000051391666649 a mesma foi rejeitada acusando que ela já existe mas a chave é diferente. Essa nota é a nota de numero 5 o que esta com diferença é o código da nota que essa é 39166664 e a que foi enviada anteriormente e foi autorizada possui um outro código. O erro esta no seu sistema que deveria gerar o código da nota de forma aleatória e salvar no banco de dados juntamente com os demais dados da nota. E ao gerar o arquivo TXT ler os dados da nota e consequente atribuir o código da nota (salvo no banco de dados) ao campo cNF. Isso evita que você tenha a rejeição de duplicidade com diferença na chave. Outra erro que existe na sua aplicação é permitir que o usuário envie a mesma nota mais de uma vez. Essa possibilidade só pode estar disponível caso ocorra erro de validação, ou seja, existem informações que não foram validadas pelos schemas e logo a nota nem sequer foi enviada para a SEFAZ. Nesse caso deve-se fazer as devidas correções, gerar novamente o XML, validar e enviar caso esteja tudo OK. Outra possibilidade de enviar novamente a nota é quando ela é enviada e a SEFAZ a rejeita por conter dados errados, por exemplo foi informado o CNPJ da matriz e a IE da filial. Nesse caso deve-se fazer as devidas correções, gerar novamente o XML, validar e enviar para a SEFAZ. Caso ocorra erro de internet como por exemplo timeout, jamais devemos enviar novamente a nota, pelo simples fato de você não saber se o erro ocorreu no envio ou no retorno do protocolo. Cabe nessa situação, carregar o XML da nota que foi enviada e realizar uma consulta. Se o erro ocorreu no retorno e a nota foi processada com sucesso o XML será atualizado com o numero do protocolo e consequentemente você pode imprimir do DANFE e segue a vida. Agora se o erro ocorreu no envio, a SEFAZ vai retornar a mensagem que a nota não consta na base de dados, ai sim você envia novamente. Dica importante: Não ative a opção para Salvar Apenas as NFe Processadas. Isso é dar um tiro no pé, pois se ocorrer um erro de internet você não vai ter o XML assinado para carregar e fazer a consulta.

Bom dia Ale, Pelo que noite o provedor ISSDSF que possui um layout próprio criou um novo WebService que segue a versão 1 do layout da ABRASF para atender a cidade São Jose dos Campos. E agora criou outro WebService que segue a versão 2 do layout da ABRASF para atender a cidade de Macapá. Logo vai ser necessário criar um novo arquivo INI com o nome DSFv2 (por exemplo) no arquivo Cidades.ini alterar o nome do provedor ou seja trocar Fiorilli por DSFv2. Criar o enumerado proDSFv2 na unit pnfsConversao e incluir esse enumerado em alguma funções que os demais aparecem. E talvez fazer alguns ajustes em outras units para que o XML seja gerado corretamente. Vai ser necessário criar uma pasta chamada DSFv2 dentro da pasta Schemas para conter os schemas que são utilizados para validação. Feito isso iniciar os testes usando o programa exemplo.

Bom dia Edmar, O Evento de Comprovante de Entrega foi criado para a transportadora, no seu caso não é uma transportadora, logo não tem como enviar esse evento. Não me recordo onde eu li, mas existe a intensão de criar o Evento de Comprovante de Entrega para as empresas que vendem e realizam a entrega da mercadoria. Acredito que isso não vai demorar muito, pois já existe os Schemas de validação para os eventos de Comprovante de Entrega e o de Cancelamento do Comprovante de Entrega. Vamos aguardar.

Bom dia a todos, Lembre-se que quando a SEFAZ retorna a rejeição: "Falha no Esquema XML" o problema é no WebService da SEFAZ, não tem nada haver com o Schema utilizado para validar o XML antes do seu envio. Outra coisa importante, não devemos misturar os Schemas da NF-e com os do CT-e e com os do MDF-e, costuma dar problema, em especial com o DistribuicaoDFe. Tenha uma pasta de Schemas para cada modelo de documento.

Bom dia, Somente o WebService do Rio Grande do Sul que tem esse serviço e não temos informações se ele foi pra frente.

Bom dia Willian, Existem casos não necessariamente a alíquota e sim outro tipo de informação que para uma determinada cidade deve-se informar de uma forma e para outra de outra forma. Neste caso na rotina que gera o XML além de filtrar por provedor tem que filtrar por cidade. Isso para mim é uma aberração, um provedor que não consegue estabelecer um padrão para todas as cidades que ele atende. Bom, acredito que o caso da alíquota esta resolvido, vou fechar esse tópico, para novas duvidas favor criar um novo tópico.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Luís Fernando, Você voltou para a revisão 20723 e voltou a funcionar, correto? Faça como eu fiz, posta a linha que gera a alíquota no caso do Ginfes. Como lhe disse as 4 ultimas revisões da unit pnfsNFSeW_ABRASFv1 são: 20118, 20621, 20738 e 20790. Logo é de se esperar que na revisão de numero 20723 a unit em questão estava com a revisão 20621, correto? Na revisão 20621 temos: proRJ, proPublica, proBHISS, proGINFES, proAbaco: Gerador.wCampo(tcDe4, '#25', 'Aliquota', 01, 05, 0, (NFSe.Servico.Valores.Aliquota / 100), DSC_VALIQ); Na revisão 20738 temos: proGINFES: if NFSe.OptanteSimplesNacional = snSim then Gerador.wCampo(tcDe4, '#25', 'Aliquota', 01, 05, 1, NFSe.Servico.Valores.Aliquota, DSC_VALIQ) else Gerador.wCampo(tcDe4, '#25', 'Aliquota', 01, 05, 0, NFSe.Servico.Valores.Aliquota, DSC_VALIQ); proRJ, proPublica, proBHISS, proAbaco: Gerador.wCampo(tcDe4, '#25', 'Aliquota', 01, 05, 0, (NFSe.Servico.Valores.Aliquota / 100), DSC_VALIQ); Como você pode ver desde a revisão 20621 até hoje a alíquota para o provedor Ginfes é gerada com 4 casas decimais.

Boa tarde Diego, Muito obrigado pela colaboração, já inclui na minha lista de tarefas.

Boa tarde Guilherme, Você esta usando o programa exemplo para realizar os testes? Se não esta, utilize, se funcionar com o programa exemplo você verifica o que esta de errado na sua aplicação

Luís Fernando, Pelo que me recordo a alíquota no caso do Ginfes sempre foi gerada com 4 casas decimais, por conta dos schemas. Gerador.wCampo(tcDe4, '#25', 'Aliquota', 01, 05, 1, (NFSe.Servico.Valores.Aliquota / 100), DSC_VALIQ) O valor tcDe4 diz que é para gerar com 4 casas decimais. o Valor 01 indica o tamanho mínimo e o 05 o tamanho máximo. As revisões ocorridas na unit pnfsNFSeW_ABRASFv1 são: 20118, 20621, 20738 e 20790. A revisão de numero 20723 se refere a unit pcnNFeW, ou seja, se refere ao componente ACBrNFe logo não tem nada haver com a NFS-e. Você deve estar confundindo o numero da revisão.

Boa tarde Augusto, Vou incluir na minha lista de tarefas. Desde já muito obrigado pela colaboração.

Boa tarde Luís Fernando, Na sua postagem anterior cuja a alíquota é 4% a imagem do XML é do RPS ou da NFS-e? Se não me falha a memória o Ginfes requer que a alíquota no XML do RPS seja informada dividida por 100, mas ao gerar o XML da NFS-e ele gera sem a divisão. E na sua ultima postagem a alíquota informada é 1% o correto não seria 4% para a referida cidade?