Italo Giurizzato Junior

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

Bom dia Walter, Peça para o seu cliente conseguir o XML dessa outra transportadora. Pois para que uma informação seja impressa no DACTE precisa constar no XML. Na página 5 do Manual do DACTE versão 1.01 temos: 1.1 Campos do DACTE O conteúdo dos campos do DACTE deverá ter a sua origem nas respectivas TAG XML do CT-e, quando conhecidos no momento da solicitação de autorização de uso. Não poderão ser impressas informações que não constem do arquivo da CT-e. Conforme dito antes o que é impresso no DACTE tem que constar no XML do CT-e. A partir da versão 3.00 o CT-e não contem mais as tags referentes ao seguro, pois elas agora são informadas no MDF-e também versão 3.00 Na página 187 do Manual do CT-e versão 3.00 você vai encontrar o grupo <seg> (#142) Informações de Seguro de Carga, mas note que esse grupo faz parte do grupo <infCTeNorm> (#131) Grupo de Informações do CT-e OS Normal. Na página 167 do mesmo manual temos o grupo <infCTeNorm> (#241) Grupo de Informações do CT-e Normal e Substituto e dentro deste grupo não existe o grupo <seg>. Temos que tomar cuidado com esse manual pois ele contem o layout do CT-e (modelo 57) que se refere ao transporte de carga e o layout do CT-e OS (modelo 67) que se refere a OS = Outros Serviços: Transporte de Pessoas, Transporte de Valores e Excesso de Bagagem. Resumindo: No CT-e versão 3.00 não se informa os dados do Seguro, essas informações devem ser informadas agora no MDF-e 3.00 No CT-e OS versão 3.00 devemos informar os dados do Seguro.

Boa tarde Arce, Acho que você esqueceu da unit pcesS5013.pas

Boa tarde Valdir, Acabei de enviar tudo, favor atualizar os fontes e reinstale usando o ACBrInstall_Trunk2, não esqueça de marcar a opção para apagar os fontes antigos.

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 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.

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

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.

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

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.

Boa tarde Lucas, Lembre-se que os Schemas são utilizados para validar o XML antes do seu envio para a SEFAZ, sendo assim se não ocorrer problemas em ambiente de homologação com ambas as configurações que você utiliza, não há o que temer ao mudar para o ambiente de produção.

Boa tarde, Favor anexar o arquivo INI e o XML gerado para que possamos analisar o problema.

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

Bom dia Thiago, Peço que aguarde alguém lhe responder, não vai ser dessa forma que você vai ganhar atenção.