Italo Giurizzato Junior

Boa tarde Dimas, O seu XML aparentemente esta correto, agora se ao validar diz que o elemento infNF é inesperado significa que os schemas que você esta usando estão desatualizados.

Boa tarde Diego, No seu XML existem palavras com cedilha e vogais acentuadas, veja: <xTexto>O valor aproximado de tributos incidentes sobre o preço deste serviço é de R$ 38,28</xTexto>

Boa tarde Leonel, O DPEC não existe mais, foi desativado pela SEFAZ. A contingência agora é através do evento EPEC.

Cardilo, Favor atualizar os fontes e testar novamente.

Boa tarde Ricardo, Você esta configurando corretamente as propriedades? Configuracoes.Geral.VersaoDF := ve310; Configuracoes.WebServices.PathEvento := <informar o path que contem os schemas>;

Boa tarde Cardilo, Desculpe não entendi, o componente esta gerando duas pastas chamadas Evento? Ou as sub-pastas como por exemplo Cancelamento não esta sendo gerada e todos os tipos de eventos estão sendo salvos na pasta Evento?

Boa tarde Dércio, Fique tranquilo, pois assim que o ACBrNFSe estiver funcionando no Trunk2 vamos divulgar.

Boa tarde, Você atribuiu o valor ve310 a propriedade: Configuracoes.Geral.VersaoDF ?

Daniel, Caso opte pela minha sugestão, vai sim ter quebra de código como se trata de um Refactoring isso foi discutindo entre nós que isso iria acontecer e não vejo essa alteração como traumática. Da forma que hoje esta implementado o PathEvento e o GetPathEvento já prevê todos os eventos: %MeuPath% \CNPJ \YYYYMM \Evento \CCe \Cancelamento \EPEC \Confirmacao \Ciencia \Desconhecimento \NaoRealizada Acredito que o problema que o Ricardo se refere é: no momento de gravar o XML do evento o componente se baseia no PathCCe ou PathCan dependendo do evento. E ao tentar ler o XML o componente se baseia no PathEvento. Se eliminarmos as propriedades PathCCe e PathCan e consequentemente o GetPathCCe e GetPathCan, teremos que realizar as correções a fim de no momento de salvar a solicitação, o retorno e o XML de compartilhamento do evento levando em conta o PathEvento. Os componentes ACBrCTe e ACBrMDFe já trabalham desta forma.

Bom dia a todos, Daniel, acredito que o problema esteja nas propriedades PathCCe e PathEvento. No meu entendimento as propriedades PathCCe e PathCan devem ser removidas e ficar somente PathEvento uma vez que o cancelamento e a CC-e são eventos. Ao utilizar o PathEvento é criado uma pasta Evento e dentro desta temos as pastas CCe e Cancelamento sendo assim vamos continuar tendo os XMLs referentes ao evento CC-e separados de outros eventos. Dentro da pasta Eventos temos ainda as pastas EPEC, Confirmacao, Ciencia, Desconhecimento e NaoRealizada, todos são eventos vinculados a NF-e, sendo que os últimos 4 se referem a manifestação do destinatário. Esses 5 últimos sitados não possuem path específicos para eles, ou seja o path deles é o PathEvento. Volto a recomendar uma padronização, ou seja, remova os PathCCe e PathCan e deixe tudo no PathEvento.

Bom dia Nilton, Desculpe pela demora em responder, sim a alteração que fiz é no Trunk2.

Bom dia Marco, O cancelamento do CT-e é um evento, sendo assim, você esta montando a rotina para o envio do evento ou esta usando o método Cancelamento? Você esta carregando o XML do CT-e a ser cancelado antes do envio do evento?

Bom dia Fabio, O componente ACBrNFSe para o Trunk2 ainda esta sendo convertido e consequentemente deve existir inúmeros erros. Sugiro ter em uma segunda maquina o Trunk para que você possa usar o ACBNFSe.

Boa tarde Dércio, O ACBrNFSe foi deixando por último em função da sua complexidade, não vou estipular prazo para finalizar o mesmo. Infelizmente não é possível ter no mesmo Delphi todos os componentes do trunk2 e o NF-e do trunk. Alem de separar em duas aplicações caso você queira já utilizar a NF-e do trunk2 deve-rá ter uma segunda maquina ou uma maquina virtual. Poderíamos ter deixado para lançar o trunk2 somente o ano que vem, assim teríamos tempo para converter tudo, mas os testes ficariam restritos a meia duzia de desenvolvedores.

Boa tarde Renata, Realmente era para ser aceito, mas tenta fazer da forma que expliquei. Pois arredondar um a um e somar da um valor, somar todos e arredondar pode dar outro valor.

Boa tarde Jeferson, E a outra que foi enviada com sucesso, você podeira anexar também?

Boa tarde, O componente ACBrNFe segue Manuais, Notas Técnicas e a legislação vigente. AJUSTE SINIEF 07/2005 - disponível no Portal Nacional da NF-e. O paragrafo primeiro da cláusula primeira diz: § 1º Considera-se Nota Fiscal Eletrônica - NF-e o documento emitido e armazenado eletronicamente, de existência apenas digital, com o intuito de documentar operações e prestações, cuja validade jurídica é garantida pela assinatura digital do emitente e autorização de uso pela administração tributária da unidade federada do contribuinte, antes da ocorrência do fato gerador. Comentário: O primeiro paragrafo se refere ao XML, pois é este que contem a assinatura digital do emitente. Item 3 da cláusula sétima diz: III - da concessão da Autorização de Uso da NF-e; Comentário: isso significa: assim que obtemos o retorno da SEFAZ com o protocolo de autorização. O paragrafo sétimo da cláusula sétima diz: § 7º Deverá ser encaminhado ou disponibilizado download do arquivo da NF-e e seu respectivo Protocolo de Autorização: I - no caso de NF-e modelo 55, obrigatoriamente: a ) ao destinatário da mercadoria, pelo emitente da NF-e, imediatamente após o recebimento da autorização de uso da NF-e; b ) ao transportador contratado, pelo tomador do serviço antes do início da prestação correspondente; II - no caso de NF-e, modelo 65, ao adquirente, quando solicitado no momento da ocorrência da operação. Comentário: Uma forma de disponibilizar é enviar por e-mail o arquivo da NF-e, como dito antes é o XML assinado e com o protocolo de autorização. Veja o que diz o paragrafo segundo da cláusula décima: Cláusula décima O emitente deverá manter a NF-e em arquivo digital, sob sua guarda e responsabilidade, pelo prazo estabelecido na legislação tributária, mesmo que fora da empresa, devendo ser disponibilizado para a Administração Tributária quando solicitado. § 1º O destinatário deverá verificar a validade e autenticidade da NF-e e a existência de Autorização de Uso da NF-e. § 2º O destinatário da NF-e modelo 55 também deverá cumprir o disposto no caput desta cláusula e, caso não seja contribuinte credenciado para a emissão de NF-e modelo 55, poderá, alternativamente, manter em arquivo o DANFE relativo à NF-e modelo 55 da operação, o qual deverá ser apresentado à Administração Tributária, quando solicitado. § 3º O emitente de NF-e modelo 55 deverá guardar pelo prazo estabelecido na legislação tributária o DANFE que acompanhou o retorno de mercadoria não entregue ao destinatário e que contenha o motivo do fato em seu verso. Comentário: Se o destinatário for uma pessoa física, o DANFE serve como nota fiscal, mas para uma pessoa jurídica e principalmente se esta for credenciada a emitir NF-e o que vale é o XML assinado e protocolado. Resumindo, você enviar somente o PDF do DANFE por e-mail, você esta infringindo a legislação, pois não estaria enviando para o cliente a nota fiscal propriamente dita. É por isso que ao executar o EnviarEmail o ACBrNFe sempre vai anexar o XML.

Boa tarde, O Componente ACBrNFe ao obter o retorno de uma consulta ao cadastro é montado uma lista com todas as ocorrências. Veja: edtIE.Text:=ACBrNFe.WebServices.ConsultaCadastro.RetConsCad.InfCad.Items[x].IE; Se você fizer o X variar de zero até a quantidade de ocorrências menos UM, terá todas as ocorrências. exemplo: for x := 0 to ACBrNFe.WebServices.ConsultaCadastro.RetConsCad.InfCad.count -1 do begin edtIE.Text:=ACBrNFe.WebServices.ConsultaCadastro.RetConsCad.InfCad.Items[x].IE; (...) end;

Boa tarde Renata, Você poderia postar em anexo uma dessas notas que foi rejeitada? Outra coisa na minha aplicação faço da seguinte forma: Produto1 = RoundTo(Valor1, -2) Produto2 = RoundTo(Valor2, -2) Total = Produto1 + Produto2 Se você fizer dessa outra forma: Total = RoundTo( Valor1 + Valor2, -2) Poderá ocorrer diferenças.

Boa tarde Nilton, Acredito não ter sido claro, veja este exemplo: procedure TCTeRecibo.Clear; begin (* // Limpa Dados do retorno; FPMsg := ''; FverAplic := ''; FcStat := 0; FxMotivo := ''; *) end; Remova os (* e *)

Boa tarde Diego, Se você informar um código de município aleatório, mas desde que tenha 7 dígitos o ACBr não vai acusar, pois o mesmo se baseia nos schemas (arquivos XSD). Dependendo da informação consta no schema os valores validos, neste caso o ACBr vai apresentar uma mensagem de erro de validação. E aproveitando tenha sempre em mente: Erro de validação: significa que o ACBr confrontou o XML gerado com o schema e algo esta errado, neste caso o envio para a SEFAZ não é realizado. Erro de Rejeição: significa que o ACBr confrontou o XML gerado com o schema, não detectou nenhum erro, ocorreu o envio para a SEFAZ, mas esta rejeitou por detectar dados não válidos. Em ambos os casos devemos fazer a correção e enviar novamente.

Boa tarde Dércio, Neste primeiro momento, a sugestão é separar em duas aplicações. A NFS-e apesar do seu XML ser extremamente simples comparado com o da NF-e, ela se torna complicado o seu refactoring para o Trunk2, por não seguir um padrão nacional tanto do layout do XML quanto do layout dos Web Services.

Boa tarde Eber, Você esta coberto de razão, a SEFAZ sempre no primeiro momento se faz de morta e diz que o problema é externo e que seus servidores e sistemas estão rodandos redondinhos. Mas acredito que com a massificação da NFC-e, esse e outros problemas vão surgir e ai o negócio vai ser colocar a boca no trombone. Quando entupir a caixa de e-mail deles com reclamações, eles vão ter que tomar uma providencia.

Bom dia Volmir, Muito obrigado pela correção, já esta disponível.

Bom Dércio, Utilize o Tortoise.