Italo Giurizzato Junior

Bom dia Celso, Tudo isso vai acabar com a implantação da NFS-e Padrão Nacional.

Bom dia Mauro, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Bom dia Weber, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Bom dia Marcio, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Bom dia Eptus, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Bom dia José, Esse tipo de consulta não foi implementado.

Bom dia André, Eu sugeri que você fizesse o teste, pois também fiz e obtive o mesmo resultado. Quando assinamos os RPS, eles são assinados de forma individual, ou seja, o método que realiza a assinatura não encontra nenhuma outra assinatura no XML. Quando assinamos somente o lote, os RPS contidos nele não possuem assinatura, logo o método assinar não encontra nenhuma outra assinatura ao realizar a assinatura no XML. Mas quando assinamos um lote que contem RPS assinados, não sei o que ocorre que torna as assinaturas dos RPS inválidas. Infelizmente ainda não encontrei uma solução para o problema.

Bom dia Renato, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Bom dia Joceandro, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Bom dia Jeihcio, Muito obrigado pela informação, você dizer a partir de quando só será aceito essa nova versão?

Bom dia Edevair, Primeiramente peço desculpa pelo erro, não são 8 zeros e sim 7 zeros. Segundo, veja esse fragmento de código do componente: if NFe.infNFe.Versao >= 4 then begin if (nfe.Det.Prod.CEST <> '') then begin Gerador.wCampo(tcStr, 'I05c', 'CEST ', 07, 07, 1, OnlyNumber(nfe.Det.Prod.CEST), DSC_CEST); Gerador.wCampo(tcStr, 'I05d', 'indEscala', 01, 01, 0, indEscalaToStr(nfe.Det.Prod.indEscala), DSC_INDESCALA); Gerador.wCampo(tcStr, 'I05e', 'CNPJFab ', 14, 14, 0, nfe.Det.Prod.CNPJFab, DSC_CNPJFAB); end; Gerador.wCampo(tcStr, 'I05f', 'cBenef', 10, 10, 0, nfe.Det.Prod.cBenef, DSC_CBENEF); end else Gerador.wCampo(tcStr, 'I05w', 'CEST', 07, 07, 0, OnlyNumber(nfe.Det.Prod.CEST), DSC_CEST); Note que a tag CEST é opcional para a versão 3.10 da NF-e e obrigatória para a versão 4, mas segundo a Nota Técnica 2016/002 versão 1.41 - página 14, as tags: CEST, indEscala e CNPJFab fazem parte de um grupo de elementos (I05b) opcionais, conforme mencionado pelo BigWings. Quanto a penalização do seu cliente, não vejo razão para temer, uma vez que a SEFAZ não esta validando essa informação, por enquanto. Agora me diz uma coisa, o CEST é utilizado para realizar a escrita fiscal e contábil bem como os SPED da vida? Se sim, é preciso então conversar com o contador do seu cliente.

Bom dia Aristarco, Não sei se poderíamos chamar esse ambiente "Produção Restrita" como ambiente de teste (homologação), se sim, o que pode esta ocorrendo, nesse ambiente o webservice só esta aceitando a versão mais recente e no de produção a versão anterior. São apenas suposições.

Diogo, Deixa vazio a propriedade e tente "debugar" para saber qual é o Path gerado, pois pode ter ocorrido alguma alteração que esta causando esse erro.

Bom dia Diogo, Pelo que entendi, dentro da pasta que contem o executável, você criou uma pasta e dentro desta colocou os Schemas, correto? Se sim, qual é o nome dessa pasta?

Bom dia Joceandro, Muito obrigado pela colaboração, ainda hoje enviarei para o repositório. Realmente vai ser necessário passar esse pente fino.

Bom dia Renato, Nem todos os eventos foram alterados para suportar a versão 2.04.01 e 2.04.02, com certeza é esse o problema.

Joceandro, Desculpe foi falha minha. Ainda hoje estarei enviando para o repositório, muito obrigado pela colaboração.

Bom dia Paulo, Refiz a geração do grupo <consigFGTS> acredito que da forma que esta agora ficou melhor. Ainda hoje vou enviar para o repositório.

Bom dia Joceandro, Você relatou alterações no evento 1200 mas a unit anexada é do 1050.

O Windows esta atualizado?

Bom dia Aristarco, No XML do evento não existe nenhuma tag que contem a versão do eSocial que esta sendo gerada. Essa informação somente aparece no namespace da tag <eSocial>, isso deveria ser suficiente para o webservice saber em qual versão o XML foi gerado. A mensagem de erro: "Leiaute do evento inválido" sugere que o evento foi gerado em uma versão e o webservice esta esperando em outra e essa outra o Layout contem diferenças. O código de erro 403 que aparece no XML de retorno não tem nada haver com o erro 403 quanto tentamos consumir um webservice e este nega pelo fato do certificado digital não ter permissão para isso. Sendo assim o problema não é o certificado digital e sim algo relacionado a versão do evento que implica em alguns evento alteração em seu layout.

Bom dia Luiz, O seu XML não possui a grupo <eSocial>. É dentro deste grupo que devemos colocar o grupo <evtTabCargo>. Faça o que o Daniel sugeriu, use o programa exemplo do eSocial para gerar o XML do respectivo evento e compare com o seu XML.

Bom dia Edevair, Sim, esta claro eu que devo ter entendido errado. Segundo a NT 2016/002 versão 1.41 a tag <CEST> é obrigatória e deve conter uma informação numérica de 7 dígitos. Segundo a NT 2017/001 versão 1.20 as regras: 9I03-30 e 9I12-30 responsáveis por validar o CEST só vão entrar em vigor em 02/07/2018. Com até essa data o CEST não vai ser validado, a minha sugestão é informar no campo CEST 8 zeros.

Bom dia, Tentou atribuir o valor xsLibXml2 a propriedade XMLSignLib?

Bom dia Geraldo, Esse arquivo "-nfse.xml" o seu conteúdo é o RPS e normalmente ele é salvo com o seguinte nome: <numeroRPS><serieRPS>-rps.xml na pasta: Recibos. Ou é salvo com o nome: <codigoUF><ano><mês><cnpjEmitente><modelo><numeroRPS>-rps.xml Já que o provedor acusa que o RPS foi processado com sucesso, e através do método ConsultarLote não retorna o XML da NFS-e, tente usar o método: ConsultarNFSePorRps. Esse método tem por finalidade obter o XML de uma NFS-e com base no numero e série do RPS, é claro que só será retornado o XML da NFS-e se o RPS foi processado com sucesso.