Italo Giurizzato Junior

Bom dia Jorge, Favor anexar a unit que você alterou para que o XML seja gerado corretamente.

Boa tarde a todos, Muito obrigado pelos alertas, favor atualizar os fontes e testarem novamente.

Boa tarde Simons, Muito obrigado pela colaboração, acredito ter resolvido a maioria dos erros. Já enviei para o repositório, favor atualizar os fontes e iniciar os testes com o programa exemplo.

Boa tarde Ronie, Se tratando da SEFAZ-MG esses problemas técnicos é normal. Toda vez que você enviar e receber a mensagem "Erro não Catalogado" significa que a SEFAZ esta com problemas. Favor entrar em contato com eles a apresentar o problema.

Vou relacionar algumas que considero muito importantes. 1. Procure ter no banco de dados todas as informações do documento, pois se o seu cliente vir a perder o XML, será possível gerar e assinar ele novamente com as mesmas informações e por fim executar o método Consultar para obter o protocolo de autorização e com isso deixar o XML completo, ou seja, assinado e protocolado, tornando-o desta forma um documento com validade jurídica. 2. Jamais informe o numero do documento como sendo o código do documento, a titulo de exemplo a NF-e: muitos atribuem o valor de nNF (numero da nota fiscal) a cNF (código da nota fiscal). Essas duas informações fazem parte da chave, logo não faz nenhum sentido serem iguais. Por recomendação da SEFAZ o valor de cNF tem que ser um numero aleatório. Logo devemos gerar esse numero e armazena-lo no banco de dados junto com os demais dados da nota. Outro detalhe importante o tamanho de nNF é de 9 dígitos, já o tamanho de cNF é 8, portanto quando o numero do documento atingir a casa dos 9 dígitos, como você vai passar esse numero para o código que só aceita 8 dígitos? Todo o que foi dito acima referente a NF-e, devemos também levar em consideração aos demais Documentos Fiscais Eletrônicos. No CT-e temos nCT (numero do Conhecimento) e cCT (código do Conhecimento), sendo que este último deve ser um numero aleatório e diferente do nCT. No MDF-e temos nMDF (numero do Manifesto) e cMDF (código do Manifesto), mesma recomendação do CT-e. No BP-e temos nBP (numero do Bilhete) e cBP (código do Bilhete), mesma recomendação do CT-e. 3. Prefira armazenar os XMLs no banco de dados em vez no Disco, isso evita que algum usuário apague sem quer os XMLs. 4. Para quem utiliza o certificado A1, prefira armazenar o seu conteúdo no banco de dados, pois desta forma não se faz necessário instalar o mesmo na maquina.

Esse erro ocorre quando o XML do DF-e - Documento Fiscal Eletrônico é gerado e assinado novamente e valor da tag <DigestValue> da assinatura não é o mesmo da tag <digVal> que é retornado junto com o protocolo de autorização ao realizar uma consulta. O motivo do DigestValue estar diferente ao gerar e assinar novamente é porque alguma informação mudou em relação a primeira vez que o XML foi gerado e enviado para a SEFAZ. A informação mais comum é o valor passado para dEmi (data de emissão), devemos passar para esse campo a data/hora e podemos usar o a função Now do Delphi, mas muitos se esquecem de salvar essa informação no banco de dados e ao gerar novamente com certeza a data e ou a hora vão estar diferentes, isso já é o suficiente para gerar um DigestValue diferente na assinatura. Boa pratica: Se você prefere sempre gerar e assinar o XML novamente, então procure ter todas as informações armazenadas no banco de dados. Por outro lado lembre-se que se você já possui o XML assinado, não faz sentido gerar ele novamente, basta carrega-lo através do método LoadFromFile ou LoadFromString ou LoadFromStream (dependendo do caso) e por fim executar o método Consultar.

Vamos supor que você perdeu o XML de um DF-e Documento Fiscal Eletrônico, seja ele uma NF-e, NFC-e, CT-e, CT-e OS, MDF-e ou BP-e. O procedimento é muito simples, basta alimentar o componente com os dados do documento, executar o método Assinar e por fim o método Consultar. Abaixo um exemplo usando o componente ACBrNFe, mas pode ser aplicado para os demais modelos de DF-e. (...) AlimentarComponente; ACBrNFe1.NotasFiscais.Assinar; ACBrNFe1.Consultar; (...) E para quem usa o Monitor: NFe.CriarNFe( arqINI ); NFe.AssinarNFe( pathNomeXML ); NFe.ConsultarNFe( pathNomeXML );

Bom dia Lopes, Cara não entendi nada o que você escreveu e qual é o problema que esta ocorrendo? Outra coisa, você vai gerar o XML do CT-e ou do CT-e OS?

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

Bom dia Sandro, Essa alteração também funciona para as demais Operações Fiscais ou somente para a 5.9? Vai funcionar para todas as cidades atendidas por esse provedor ou somente para Santa Cruz do Sul?

Roberto, Esse provedor não foi implementado, peça a eles um XML exemplo de envio de RPS.

Bom dia Gumercino, Muito obrigado pela colaboração, já passei a sua alteração para o pessoal que conhece bem o Fast Report para analisa-la.

Bom dia Roberto, Afinal a cidade de Bragança Paulista usa o provedor GovDigital ou o Giap?

Bom dia, Uma coisa é você incluir a cidade no arquivo Cidades.ini para que seja possível o envio de RPS para o provedor dessa cidade. Segundo é você informar os dados corretos no componente referente ao RPS. O que esta ocorrendo é que você enviou um RPS com informações erradas.

Bom dia a todos, Que eu saiba ninguém esta implementando esses 2 novos eventos. Pelo que li na Nota de Documentação Evolutiva - NDE, esses eventos vão se tornar obrigatórios a partir de janeiro de 2019. A sua implementação no componente não vejo problemas, basta tomar como base a implementação dos outros. O problema maior é quanto ao Schema (arquivo XSD) que o componente se utiliza para validar o XML após a sua geração e assinatura.

Bom dia Luiz, Anexa um XML de retorno referente ao envio de um evento.

Bom dia Rafael, Fica difícil implementar um novo provedor cujos arquivos XSD (schemas) estão "bichados", os XML de exemplos também.

Bom dia, A primeira mensagem de erro está clara que a informação do campo <NumeroLote> deve ser um numero inteiro e você atribuiu "LOTE2" que é uma informação alfanumérica. Já a segunda, chegou a abrir o arquivo XSD (Schema) do provedor em questão e procurou pelo campo <RegimeEspecialTributacao> para saber quais são os valores validos?

Bom dia a todos, Todas as cidades atendidas pelo provedor Pronim cujo Webservice segue a versão 2 do layout da ABRASF mudaram a versão do XML para 2.03 ou ainda algumas vão permanecer na versão 2.02?

Bom dia Felipe, Muito obrigado pela sua colaboração. Uma observação: Favor atualizar todos os fontes de todas as pastas e reinstale a Suite ACBr usando o ACBrInstall_Trunk2, pois os seus fontes estão desatualizados, notei isso através do arquivo INI do provedor que você anexou.

Bom dia Luiz, Tente desta outra forma: xID := ACBreSocial1.Eventos.Iniciais.S1000.Items[ x ].ID;

Bom dia Edgar, Onde você viu esses eventos? Em qual versão do e-Social?

Bruno, Segundo a Nota Técnica 2016/002 versão 1.60 temos: 5 Campos do DANFE Nesta nova versão não haverá alteração no leiaute do DANFE. As informações relativas ao Fundo de Combate à Pobreza (FCP) devem ser informadas:  No campo de "Informações Adicionais do Produto, tag: infAdProd", os valores informados por item nos campos (vBCFCP, pFCP, vFCP, vBCFCPST, pFCPST, vFCPST), quando existirem.  Os valores de totais do FCP (id: W04b e W06a) devem ser informados em "Informações Adicionais de Interesse do Fisco, campo “infAdFisco", quando existirem."

Bom dia Thiago, Mas para a SEFAZ-Autorizadora que você esta enviando a NFC-e já esta aceitando a versão 2 do QR-Code?

Bom dia João, Essa linha faz parte do código do programa exemplo? Se sim, corrige, em vez de WBResposta mude para WSResposta.