Italo Giurizzato Junior

Boa tarde Duarte, Desculpa, mas isso não ajuda em muita coisa, pois o que eles forneceram o componente consegue gerar sem nenhum problema e temos os Schemas para validar. A questão é que o XML de envio do Lote (por exemplo) tem que ser envelopado, necessito de um exemplo de envelopamento, caso contrario vamos ficar na tentativa e erro.

Boa tarde, Se você estiver com todos os fontes de todas as pastas atualizadas a resposta é: SIM. O ACBrNFe já esta pronto para emitir NF-e cujo emitente é um Produtor Rural e se for necessário a emissão de MDF-e, o componente ACBrMDF-e também já esta preparado. Arregace as mangas e inicie os testes.

Boa tarde, Nesses vários anos que dou manutenção no componente ACBrNFSe notei o seguinte: 1. Os provedores que seguem o layout da ABRASF seja a versão 1 ou 2 não conseguem seguir um padrão. 2. Tem provedor que não consegue manter um padrão entre as cidades que ele atende. Como você pode ver, é uma zorra a NFS-e. Tem um provedor que para uma determinada cidade se faz necessário incluir o NameSpace no inicio do XML do RPS caso contrario o mesmo não é aceito. O pior que essa exigência é só para uma cidade, as demais não precisam. Não vejo a hora da NFS-e Padrão Nacional começar pra valer, assim acaba com toda essa palhaçada.

Boa tarde Henrique, Em vez do libCapicomDelphiSoap ou libCapicom, tentou usar o libWinCrypt ou libOpenSSL?

Boa tarde Leonard, Se o erro é de Schema não tem nada haver com DLL. Verifica se no seu cliente o XML do RPS esta sendo gerado exatamente igual nos seus testes com a sua maquina.

Roberto, Veja a definição do grupo <Comp> na página 164 do Manual do CT-e versão 3.00

Boa tarde Cleyton, Os seus fontes estão desatualizados, favor atualizar e faça um novo teste.

Boa tarde Roberto, Você não usa o componente para gerar o XML? Outra coisa o grupo <Comp> não tem nada haver com CT-e Complementar, esse grupo se refere a Composição da prestação, ou seja, o que compõem o valor total da prestação <VTPrest>. Nesse grupo informamos o nome e o valor do item que compõe, inclusive esse grupo pode se repetir varias vezes, pois o valor total da prestação pode ser composto por vários itens.

Boa tarde Walmir, Os ajustes são tão pequenos que na minha aplicação não levei mais do que 20 segundos para corrigir e compilar com sucesso.

Bom dia a todos, Foi feito uma generalização nas Units: pcnConsCad, pcnRetConsCad, pcnConsStatServ, pcnRetConsStatServ, pcnDistDFeInt e pcnRetDistDFeInt. A motivação é porque elas aparecem de forma repetidas com nomes diferentes nos fontes dos componentes ACBrNFe, ACBrCTe, ACBrMDFe e ACBrBPe. A generalização e migração para a pasta PCNComum faz com que tenhamos mais controle das correções e melhorias, sem falar na redução de código. Infelizmente ao generalizar o pcnRetDistDFeInt ocorreu uma quebra de código, pois se fez necessário alterar o nome de uma classe e de algumas propriedades publicas. Para quem usa o DistribuicaoDFe será necessários fazer alguns ajustes no código da aplicação. Trocar os resNFe por resDFe e chNFe por chDFe (para quem baixa as Notas). Trocar os resCTe por resDFe e chCTe por chDFe (para quem baixa os Conhecimentos). Trocar os resMDFe por resDFe e chMDFe por chDFe (para quem baixa os Manifestos).

Com certeza.

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

Bom dia, Acredito ter encontrado o problema. Como você utiliza o Monitor será necessário primeiro eu disponibilizar a correção para que o pessoal possa recompilar o Monitor e por fim você baixar a ultima versão do Monitor.

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

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

Bom dia Carlos, O componente possui o método DistribuicaoDFe para poder baixar Notas emitidas contra o seu CNPJ, que não é o seu caso. Uma saída seria gerar o XML da nota exatamente como foi gerado da primeira vez, assinar e por fim executar o método Consultar, pronto você terá o XML novamente com o protocolo de autorização. Outra saída é tentar baixar o XML via site da SEFAZ.

Boa tarde Arce, Muito obrigado pela colaboração, já enviei para o repositório.

Bom dia Duarte, Entre em contato com o provedor e tenta conseguir um exemplo completo de envio, ou seja, com a tag <Envelope> e não apenas o RPS, pois este já sabemos o seu layout.

Bom dia Robson, A mensagem da rejeição é clara, existe um MDF-e de numero 4 mas a chave não é essa. Você tem o XML do MDF-e que deseja encerrar para que possamos comparar as chaves? Quanto a erro de index precisamos saber descobrir o motivo.

Nas últimas Notas Técnicas onde constam as novas informações referentes a tributos, no final consta que ainda não se tem a intensão de alterar o DANFE e que as novas informações devem constar em informações adicionais do item ou em observação dependendo do caso. Eu no seu lugar não me atreveria a fazer uma alteração no layout e sim seguir as recomendações que constam nas NT. Quem sabe este ano saia uma NT apresentando um novo layout do DANFE.

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

Bom dia, Não entendi muito bem o que você deseja. Dependendo do cliente você quer que determinadas informações sejam impressas ou não no DANFE, é isso? O teu cliente não tem o que querer, é preciso ver no Manual e nas Notas Técnicas se uma determinada informação quando diferente de zero (no caso de tributos) deve ser impressa no DANFE ou não e onde deve ser impressa caso seja exigido. Se o cliente teimar que não quer que a informação seja impressa mostre para ele o Manual ou Nota Técnica que dispõe da obrigatoriedade da impressão.

Evandro, Favor atualizar os fontes e refaça os testes.

Boa tarde Evandro, Agora entendi o problema, vou tentar encontrar uma solução.

Boa tarde, Muito obrigado pela colaboração, vou analisar o que você fez e tentar descobrir o que esta errado.