IvanGoncalves

Certo, então o conteudo do XML após a consulta, é como o proprio webservice retorna? Então nao tem o que alterar, certo?

após realizar o cancelamento da NFS-e, o componente atualiza o XML de: false para true 2012-10-05T08:50:46.548-03:00 ou seja, coloca "true" para a TAG "", e acrescenta a TAG "". para armazenar a alteração do XML no banco de dados, acesso a propriedade "objACBrNFSe.NotasFiscais.Items.XML_NFSe". Minha duvida é a seguinte... Em um XML de uma NFS-e cancelada, gerada atraves do proprio site de emissao da Betha, existe as informações do pedido de cancelamento, ou seja, as mesmas TAGs do XML utilizado para enviar a solicitação de cancelamento. Veja a seguir: 699 85111854000106 4206900 true 2012-09-14T16:00:10.060-03:00 Será que existe algo para corrigir no componente, ou isto não se faz necessário?

Ítalo, muito obrigado pelas informações... Referente ao protocolo, já havia me dado por vencido, realmente não tem como recuperar o protocolo nessa situação, vai a dica, caso isso aconteça, eu verifico as propriedades: "objACBrNFSe.WebServices.ConsSitLote.NFSeRetorno.InfSit.MsgRetorno.Items[0].Codigo" quando estou enviando "objACBrNFSe.WebServices.CancNfse.NFSeRetorno.InfCanc.MsgRetorno.Items[0].Codigo" quando estou cancelando caso o valor seja "E10" quando estou enviando ou "E79" quando estou cancelando, então processo normalmente salvando no banco as informações que acho interessante de armazenar, só não o protocolo é claro. Referente à NF-e 3.0, parece que vai haver algumas mudanças consideráveis, conforme as que voce mencionou. Assim que pudermos iniciar os testes, provavelmente haverão muitos tópicos a serem discutidos. Grato.

E aí pessoa do ACBr, será que ninguém tem alguma informação para compartilhar???? No fórum da Betha ninguém responde também...

Estou com o mesmo problema, mas em momento diferente. Quando envio o RPS e o webservice processa e retorna a NFS-e normalmente, consigo pegar todas as informações necessárias para armazenar no banco de dados: objACBrNFSe.NotasFiscais.Items.NFSe.Protocolo; objACBrNFSe.NotasFiscais.Items.NFSe.CodigoVerificacao; objACBrNFSe.NotasFiscais.Items.NFSe.Situacao; objACBrNFSe.NotasFiscais.Items.NFSe.dhRecebimento; objACBrNFSe.NotasFiscais.Items.NFSe.Numero; Mas caso ocorra um problema no envio, onde o lote foi processado mas nao retornou a NFS-e (geralmente por problemas no webservice), não consigo consultar e obter o numero do protocolo e a situacao. -> Na consulta "objACBrNFSe.ConsutarNFSeporRps()", me retorna o XML da NFS-e, que não tem o numero do protocolo. -> Na consulta "objACBrNFSe.ConsutarNFSe()", é o mesmo XML da consulta anterior, porém, vão aparecer várias NFS-es de acordo com o período passado como parametro. Mas possui o mesmo problema da consulta "objACBrNFSe.ConsutarNFSeporRps()". -> Na consulta "objACBrNFSe.ConsutarSituacao()", preciso passar o protocolo como parametro, mas justamente o que preciso é saber qual o protocolo, pois vamos supor que não consegui obter o numero do protocolo na primeira tentativa de envio. -> Na consulta "objACBrNFSe.ConsutarLoteRps()", também preciso informar o protocolo como parametro. Para o componente da NF-e, funciona perfeitamente a lógica que apliquei: caso nao consiga receber resposta do webservice na primeira tentativa de envio, permito ao usuario enviar novamente e caso a mensagem que retornar seja de rejeição por duplicidade, apenas realizo uma consulta pela chave e o próprio componente se encarrega de preencher as propriedades que necessito gravar no bando de dados (protocolo, recibo, data/hora de autorização, situação, etc) e caso ela tenha sido autorizada, precesso a NF-e normalmente como se fosse a primeira tentativa de envio. Quando renvio um RPS que já foi processado, a mensagem de erro que o componente gera é "RPS ja informado. /" e nenhuma das consultas que citei acima atualiza as propriedades. Será que consegui deixar claro a minha dificuldade? Teria alguém aí que tenha passado pela mesma dificuldade? Grato

segue em anexo UNICRED.pdf BB.pdf

Agora vem o outro lado da questão... Estou implementando para uma cooperativa que tem convenio com o Bradesco, e o nome do cedente não é o cooperado/correntista, é a razao social da cooperativa e o CNPJ da cooperativa, entao deveria ter uma opcao para nao imprimir desta forma, imprimindo apenas o conteudo do campo "fBoletoFC.ACBrBoleto.Cedente.Nome", que já parametrizo com a informação correta para esta cooperativa de credito. Fiz as alterações necessárias sem interferir nos bancos que já estão homologados, interessa realizar as alteraçoes no componente? Grato

QuickReport... Já vi que no Fortes esta implementado, vou tentar instalar o fortes... Obrigado

Conforme a norma do BACEN, com base na Lei nº 12039/09, o Banco do Brasil exigiu em homologação, que seja impresso o CNPJ do Cedente, endereço completo (inclusive cidade-UF), no recibo do sacado. Já homologuei em outros bancos e nenhum exigiu esta norma do BACEN. Preciso da Opinião de mais pessoas, onde seria o melhor local para imprimir estas informações? 1) Junto com o nome do cedente? (Problema: o campo é pequeno e em alguns casos nao será possível imprimir o endereço completo, a nao ser que seja impresso em mais de uma linha, o que vai deixar o lauoute do boleto meio estranho) 2) Nas instruções de cobrança? (Problema: vai ser impresso tambem na ficha de compensação, a nao ser que sejam feitos alguns ajustes) 3) Abaixo das instruções de cobrança e ao lado das informações do sacado? Sacado: OPERSUL PILÃO LTDA Cedente: 99.999.999/0001-99 RUA 11 DE MARÇO 62 AV. CENTRAS 639 89140000 CENTRO IBIRAMA SC 89140000 CENTRO IBIRAMA-SC Sacador/Avalista: Se é para expressar as opiniões, gostei mais da última... Aguardo...

Outra questão, sei que esta situacao será muito difícil de acontecer, mas não impossível: Ao tentar enviar o 20º evento, acontece um erro: Falha na validação dos dados da carta de correção '20' violates pattern constraint of '[1-9][1][0-9]{0,1}'. The element '{http://www.portalfiscal.inf.br/nfe}nSeqEvento' with value '20' failed to parse. Consultei a NF-e e consta apenas 19 eventos, e o erro acontece quando envio o vigésimo... enfim, só para ficar registrado, nao é nada tão urgente, mas pelo que entendi é possível enviar 20 eventos... Talvez exista alguma explicação. Será que a autorização de uso tbm é um evento?

Voltando ao assunto do retorno 573 - Rejeicao: Duplicidade de Evento, tenho duvidas... Pode acontecer de o usuario enviar e por algum motivo o sistema nao conseguir pegar o retorno (protocolo, etc..), ao tentar enviar novamente, retorna o erro "573". Ao enviar uma NF-e, e caso ocorra essa mesma situacao, ao tentar enviar novamente pode acontecer de retornar 204, caso ela já tenha sido autorizada, e nesse caso, realiza-se uma consulta: objACBrNFe.WebServices.Consulta.NFeChave := 'chave de acesso'; objACBrNFe.WebServices.Consulta.Executar" Entao as propriedades das classes do ACBr passar a conter os dados assim como se fosse o primeiro envio... A pergunta é a seguinte: Existe a possibilidade de realizar a consulta para a carta de correção eletronica, para que o usuario nao tenha que criar um novo evento para a carta de correcao, pois testei realizar a consulta como descrevi acima, mas nao sei exatamente como proceder apartir daí, caso seja da mesma forma? Grato...

Tenta remover tudo que vc ja instalou e tenta instalar com o AIC Certisign que vc encontra no proprio site da Certisign... Este Assistente de Instalacao de Certificados instala a hierarquia ICP Brasil, Driver de leitora e tudo que vc precisa. Lembre-se se clicar com o botao direito e executar como administrador... Espero ter ajudado...

Ententi... Italo, mais uma vez muito obrigado...

Ótimo, Muito obrigado Italo... Eu utilizo "CSTICMSToStr(ACBrCTe.Conhecimentos.Items[n].CTe.Imp.ICMS.SituTrib)" para pegar o CST... e utiligo para pegar os valores: "ACBrCTe.Conhecimentos.Items[n].CTe.Imp.ICMS.ICMS00.vBC" "ACBrCTe.Conhecimentos.Items[n].CTe.Imp.ICMS.ICMS00.pICMS" "ACBrCTe.Conhecimentos.Items[n].CTe.Imp.ICMS.ICMS00.vICMS" ou "ACBrCTe.Conhecimentos.Items[n].CTe.Imp.ICMS.ICMS90.vBC" "ACBrCTe.Conhecimentos.Items[n].CTe.Imp.ICMS.ICMS90.pICMS" "ACBrCTe.Conhecimentos.Items[n].CTe.Imp.ICMS.ICMS90.vICMS" depende do CST é claro... Mas retorna sempre o "CST00" e os valores todos zerados... Eu descobri que na unit "pcteCTeR" no método "function TCTeR.LerXml: boolean;" a partir da linha 520 foi implementada uma diretiva de compilacao "PL_103" e "PL_104". Na "PL_103", procura pela tag "CST00" e na "PL_104" pela tag "ICMS00"... Como nao tenho programa para emissao de CT-e, nao sei se alterou alguma coisa no leiaute do CT-e ou é problema no fonte mesmo, mas nos XML que tenho aqui nao existe a TAG "ICMS00" ou "ICMS20" ou "ICMS90", etc... mas sim "CST00" ou "CST20" ou "CST90", etc... por isso nao busca os valores nem o CST. Grato...

Bom dia pessoal... Tenho uma funcionalidade muito util em meu sistema, onde o meu usuario pode importar o arquivo XML de uma NF-e ou CT-e... Sei que muitos outros sistemas possuem esta mesma funcionalidade e por isso peço uma ajuda, ja que nao encontrei nada a respeito no forum... Estou com dificuldades para buscar na classe do CT-e, qual o CST do ICMS definido no arquivo XML e claro, os respectivos valores... Procedimento padrao: "ACBrCTe.Conhecimentos.LoadFromFile(OpenDialog.FileName);" Para cada CST, os arquivos XML (NF-e/CT-e) possuem TAG diferentes, mas para importar a NF-e, eu consigo verificar qual o CST apenas dando o comando "OrigToStr(ACBrNFe.NotasFiscais.Items[n].NFe.Det.Imposto.ICMS.orig) + CSTICMSToStr(ACBrNFe.NotasFiscais.Items[n].NFe.Det.Imposto.ICMS.CST)", ou qualquer campo, sem se preocupar em acessar especificamente a classe do CST que esta no arquivo XML. Mas no CT-e nao consigo, pois consigo apenas acessar diretamente a classe do CST especifico, como por exemplo: "ACBrCTe.Conhecimentos.Items[n].CTe.Imp.ICMS.CST00.CST" para o CST "00" ou "ACBrCTe.Conhecimentos.Items[n].CTe.Imp.ICMS.CST20.CST" para o CST "20". Na classe da NF-e, logo apos a propriedade "imposto" tem "ICMS" (apenas "ICMS") e a partir daí, consigo acessar qualquer campo dos impostos de ICMS, mesmo que o CST é o 60 e o unico campo informado no XML é o proprio CST e a origem. No CT-e, apos a propriedade "Imp" tem "ICMS", igual a NF-e, mas nesse momento nao tenho a propriedade "CST" mas preciso saber qual CST para acessar a classe e pegar as informaçoes dos campos referidos a cada CST... Se eu acesso "ACBrCTe.Conhecimentos.Items[n].CTe.Imp.ICMS.ICMS00.CST" o valor retornado é "cst00" e se eu acesso "ACBrCTe.Conhecimentos.Items[n].CTe.Imp.ICMS.ICMS20.CST" o valor retornado é "cst20", mas no arquivo da CT-e tem a tag "CST20"... o mesmo acontece se no XML tem a tag "CST00". P.S.: além de tudo isso, não consigo pegar os valores da BC, Aliq e valor do ICMS, pois esta sempre zerado... Agradeço se alguém puder me ajudar.

E uma dica para os desenvolvedores de sistemas, assim como eu: o XML nada mais é que um arquivo texto, se o programa tem qualquer procedimento de backup, é só criar um campo texto no banco de dados, e salvar o arquivo texto nesse campo... após enviar a NF-e ou após importar o arquivo do fornecedor...

Por acaso chegasse a testar? Pois consegui baixar nas duas situacoes, ou seja, quando a PJ é emitente e destinatario, e consegui baixar sem problemas e mais de uma vez cada XML...

No portal da NF-e, na consulta completa, no rodapé da tela, tem um botão "Download do documento". Isto é recente, mas é possível sim baixar o XML, mas tem que ter o certificado instalado no navegador que for fazer o download.

Para complementar... editei o arquivo XML antes de importar e removi a TAG "<?xml version="1.0" encoding="UTF-8"?>" ou apenas deixar em branco onde tem o texto UTF-8, funciona 100%...

Tenho o mesmo problema na importacao do arquivo xml de fornecedores... Percebi que ao fazer um LoadFromFile do arquivo XML em um componente "memo", o problema é o mesmo... Será que teria alguma coisa a ver com a TAG "<?xml version="1.0" encoding="UTF-8"?>" Tenho conhecimento do que isto significa para o arquivo XML, mas fala em UTF-8 e como os colegas acima sugeriram utilizar a função Utf8ToAnsi()... Espero ter ajudado!

Atualizei o componente e agora aparece no meu arquivo "000119106" e "000021092"... Parace que alguem fez a correção, obrigado...

No manual todos os registros que tem o campo CFOP esta definido como Numerico. Nos fontes do ACBr, em alguns registro está como numerico e outros como string, mas ao meu ver nao faz diferença.

Percebi algo muito estranho na geração do SPED PIS/COFINS... Tenho duas notas de celulares que meu cliente lançou como modelo 22: uma com o numero 119106 e outra com o numero 21092. Na primeira, apareceu no campo NUM_DOC "05022226" ao inves do numero informado, e a segunda nota, "29042505". Veja os registros D500 e filhos... |D500|0|1|11707|22|00|1||05022226|02122011|15122011|259,85|0,00|259,85|0,00|0,00|0,00|259,85|44,17||4,29|19,75| |D501|50|259,85|13|259,85|1,65|4,29|| |D505|50|259,85|13|259,85|7,60|19,75|| |D500|0|1|11707|22|00|1||29091957|02122011|15122011|998,35|0,00|998,35|0,00|0,00|0,00|998,35|169,72||16,47|75,87| |D501|50|998,35|13|998,35|1,65|16,47|| |D505|50|998,35|13|998,35|7,60|75,87|| Será que acontece só no meu sistema, ou ninguem percebeu isto ainda? Detalhe: no SPED Fiscal funciona certinho... Alguém poderia testar, por gentileza?

Ok, agora funcionou... exclui a pasta ACBrDiversos e deixei o SVN baixar novamente. Eu havia baixado esta semana, nao sei pq nao estava validando, mas o importante é que funcionou... Muito obrigado!

Sim, esta atualizado... a ultima atualização foi a 2 dias...