Italo Giurizzato Junior

Boa tarde ALA, Os schemas indica que varias TAGs do grupo <valores> são opcionais, ou seja não precisa ser geradas. Mas o WebServices dos caras não segue o schema, exige que as mesmas sejam geradas mesmo com o valor zero. A ordem dessas TAGs não seguem o schema e o manual, pois o WebServices rejeita o XML do RPS. Concorda que fica dificil de trabalhar desta forma? Sugestão entrar em contato com eles e solicitar um modelo de XML de RPS que é aceito pelo WebService, bem como o schema para poder valida-lo antes do envio. Sem isso, meu caro, é ficar na TE - Tentativa e Erro.

Bom dia Vanderlei, A cidade de Três Coroas/RS se utiliza do provedor GovBR. Você configurou corretamente o programa exemplo para utilizar os schemas do GovBR?

Quem gera o XML do RPS e consequentemente a sequencia de TAGs é o componente. Agora que gera o XML da NFS-e é o webservice do provedor. Assim que o componente obtem o retorno contendo a NFS-e, o componente o extrai e salva em disco com o nome: <num>-nfse.xml dentro da pasta NFSe.

Bom dia Cláudio, Você tem razão, o fragmento de código disponibilizado a titulo de exemplo esta errado, preciso corrigir.

Bom dia ALA, Se você comparar o grupo <valores> do XML (2NFS-RPS.xml) que você postou como anexo com a imagem (lado direito) que foi posta no post #1, que é a estrutura gerada pela prefeitura, o respectivo grupo, esta exatamente igual, ou seja todas as TAGs estão presentes e na mesma ordem. E a mensagem de rejeição que você postou agora diz que a TAG OutrasRetencoes esta fora do lugar. No manual em PDF que também você postou, note que na página 21 na estrutura do TcValores a TAG OutrasRetencoes vem antes de BaseCalculo. E tem mais note que as TAGs DescontoCondicionado e DescontoIncondicionado estão inverdidos conforme o XML gerado pela prefeitura, postado no post #1.

Bom dia Afonso, O que o impede de renovar o seu certificado digital para continuar a emitir NF-e?

Bom dia William, Acredito eu que a intensão de mudar o valor nNF foi motivado por uma falha no sistema que acabou gerando duas notas com o mesmo numero correto? Se sim, a intensão de carregar o XML com o numero errado e gera-lo novamente com o numero correto, visando agilizar o processo, fica a dica. Ao alterar o valor de nNF e ou cNF devemos atribuir vazio ao campo ID, pois ao carregar o XML este campo contem a chave da NF-e e caso seja executado o GerarNFe, a chave não se altera. Por outro lado se for executado: nfe.infNFe.ID := ''; o componente gera uma nova chave e a atribui ao campo ID. Posso estar errado, mas o André, Daniel, Isaque, ... podem me corrigir, o correto não seria carregar o XML e altear os campos (pricipalmente estes e outros que fazem parte da chave) e executar o GerarNFe e sim, alimentar o componente do ZERO com o dados agora corretos e mandar gerar.

Boa tarde Jairo, A mensagem da rejeição é clara, e diz que já existe um outro evento de CC-e vinculado ao CT-e. No caso da CC-e existe um numero sequencial de eventos: infEvento.tpEvento := teCCe; infEvento.nSeqEvento := xNumSeq; // onde xNumSeq é do tipo Integer e é um numero sequencial 1, 2, 3, 4... infEvento.detEvento.xCondUso := ''; Outra coisa: grupoAlterado := 'rem'; campoAlterado := 'Endereço Remetente'; valorAlterado := 'Rua das flores, 333'; esta errado o correto é: grupoAlterado := 'rem'; campoAlterado := 'enderReme'; valorAlterado := 'Rua das flores, 333';

Boa tarde ALA, Favor atualizar os fontes e testar novamente.

Boa tarde Jonas, Obrigado pela colaboração, Favor atualizar os fontes e testar.

Boa tarde Wagner, Favor atualizar os fontes e testar novamente.

Boa tarde Rodrigo, Você só pode efetuar o Encerramento de um MDF-e quando o serviço estiver realizado. Se o segundo foi rejeito significa que a origem é igual em ambos. Vamos a outro exemplo que deve funcionar: MDF-e 1 origem - São Paulo destino - Bahia Motorista 1 Placa 1 MDF-e 2 origem - Bahia destino - Amazonas Motorista 1 Placa 1 Note que neste exemplo existe uma lógica, ou seja, o caminhão sai de São Paulo e vai até Bahia onde parte da carga é descarregada, em seguinda parte para o Amazonas onde o resto da carga é descarregada. Devemos lembrar que no MDF-e 1 deve conter todas as NF-e de todas as cargas, incluido as que vão ser entregues no Amazonas. Por outro lado no MDF-e 2 devemos incluir somente as NF-e das cargas vão ser entregues no Amazonas. Espero ter ajudado.

Boa tarde Alan, Se não me falha a memória Dueto é o nome do produto, ou seja, o sistema de NFS-e desenvolvido pela GovBR e que é instalado em algumas prefeituras. Alem dos schemas é necessário as URLs dos webservices, tanto do ambiente de homologação quanto de produção.

Boa tarde Nellien, Muito obrigado pela colaboração. Pode atualizar os fontes.

Bom dia Sandro, Atualizando a informação do Juliomar. O componente ACBrMDFe e já esta no trunk. Muitos usuários do fórum já estão utilizando-o tanto no ambiente de homologação como em produção. Com relação de incluir o MDF-e no ACBrNFeMonitor ou criar um monitor só para ele, somente os responsáveis pelo desenvolvimento do monitor podem lhe responder como e quando vai ser incluido.

Bom dia Cristiana, Favor postar como anexo o XML da NF-e que foi enviado e rejeitado. Para que possamos analisar.

Bom dia Luighi, Você esta compilando a aplicação com a opção Build que esta no menu Project? Não existe nenhuma DCU antiga perdida ? O Delphi esta configurado para salvar os arquivos DCU em uma pasta especifica ou são salvos na mesma pasta do fonte (padrão) ?

Boa noite menegante, Acredito que o seus fontes estão desatualizados, pois o meu esta desta forma: smtp.FullSSL := SSL; smtp.AutoTLS := TLS; if (TLS) then smtp.StartTLS; desde 13/12/2013

Boa tarde Idez, A Natureza que você se refere é a Natureza de Operação? Se sim, segundo o Schema do provedor Thema os valores aceitos são: <xsd:simpleType name="tsNaturezaOperacao"> <xsd:restriction base="xsd:byte"> <xsd:pattern value="51|52|58|59|61|62|63|64|68|69|78|79"/> </xsd:restriction> </xsd:simpleType> O componente aceita todos exceto o 79, pois não sei do que se trata. TnfseNaturezaOperacao = ( noTributacaoNoMunicipio, noTributacaoForaMunicipio, noIsencao, noImune, noSuspensaDecisaoJudicial, noSuspensaProcedimentoAdministrativo, noNaoIncidencia, noTributacaoNoMunicipio51, noTributacaoNoMunicipioSemISS52, noNaoTributa58, noSimplesNacional59, noTributacaoNoMunicipio61, noTributacaoNoMunicipioSemISS62, noTributacaoForaMunicipio63, noTributacaoForaMunicipioSemISS64, noNaoTributa68, noSimplesNacional69, noNaoTributa78 );

Boa tarde Wagner, O componente ACBrCTeDACTEQR possui a propriedade email. ACBrCTeDACTeQR.Email := sEmail; // e-mail do emitente do CT-e

Boa tarde Luighi, Depois de ter instalado tudo, você seguiu esse passo a passo: Property_Does Not Exist.txt que esta dentro da pasta ...\Fontes\ACBrNFSe ?

ALA, Primeiramente, favor tomar cuidado ao postar. A sua questão é referente ao NFS-e e você postou no forum do CT-e. Segundo, favor atualizar os fontes e testar novamente.

Bom dia Roberto, Ficou faltando a unit ACBrProvedorGovBR com a inclusão das URLs de Homologação e Produção.

Bom dia NeoSquare, Lembre-se que agora o componente ACBrNFe possui 2 propriedades novas: ModeloDF e VersaoDF Se voce atribuir a essas propriedades os valores: ModeloDF := moNFe; VersaoDF := ve200; Você esta informando ao componente que ele deve gerar o XML da NF-e na versão 2.00 E a alteração que fiz no que diz respeito as URLs para o Estado do Espirito Santo, não vai influenciar em nada, uma vez que a linha que adcionei esta comentada, logo nem sequer vai ser compilada.

Bom dia Luighi, Com certeza algum passo do passo a passo que disponibilizei você não esta executando.