farnetani

Italo, na verdade ele está sim validado. Porém se trata de um XML de um fornecedor e o erro está ocorrendo quando vou importá-lo para dentro do meu sistema, sacou? Teste fazer uma importação do mesmo pelo exemplo que está lá no ACBR para você ver o erro. Grato, Arlei F. Farnetani Jr.

Pessoal, estive vendo que nao tem na chave PIS um campo correspondente existente na chave COFINS, se trata do campo vBCProd a mesma não existe no PIS... Isso é normal???

Pessoal, detectei meio que sem querer um erro no processo de validação do xml pelo componente acbr. Gostaria que testassem. Validei o mesmo xml pelo site: https://www.sefaz.rs.gov.br/NFE/NFE-VAL.aspx Pelo exemplo do componente já dá o seguinte erro: violates pattern constraint of '[0-9]{14} Apontando o campo CNPJ...porém o XML está tudo ok...pelo debug notei que é na parte da signature que acontece o raise do erro... Segue o xml para vcs procederem com o teste... Se tiver uma solução me dá um aviso...grato! 35130403561951000128550010000304071015203501.xml

Sim é claro. Na verdade já vem no seu exemplo preenchido. Eu só clico em incluir boleto (1 vez) e depois vou em imprimir. Primeiro naturalmente como eu já disse eu mudo para o componente do FastReports.

100% atualizado...atualizo via svn...deletei o arquivo e fiz o update pra ver...e continua o problema. A única coisa que fiz de diferente é mudar os pacotes do fastreports que no que vem aponta pra frx14 e no meu eu coloco para frx10. Mas se vc já mexe/trabalha com o fastreports olhando o que te mandei já vai notar que realmente tem erros no arquivo BoletoFR3.fr3 Ai eu modifiquei o meu para funcionar e funcionou. Segue em anexo. Tente pegar o exemplo que vem e jogue o componente do fastreports do acbrboleto e teste a impressao com ele pra vc ver.

O erro que ocorre é esse: Project AcbrBoletoDemo.exe raised exception class EvariantTypeCastError with message 'Could not convrt variant of type (String) into type (Double)'. Eu entrei dentro do código do arquivo BoletoFR.fr3 e notei que realmente existem campos do tipo String que estão com formato do tipo data sendo que o mesmo é string. Acredito que isto esteja incorreto, certo?

rsrsrs...vou falar isso pra minha noiva que trabalha há 12 anos no mercantil. Mas aqui em MG o mercantil é um banco muito bom de se trabalhar, pelo menos eu acho. Valeu pelas dicas. Estive olhando, me parece que alguém já implementou...estarei revisando o mesmo e homologando...aí posto aqui. Encontrei alguns problemas relacionados ao BoletoFR.fr3 disponível junto com o demo...me parece q dá erros de conversão do tipo string para date.

Pessoal estou tendo problemas com o arquivo BoletoFR.fr3 no exemplo que vem do site. Tipo conversão de string to date... Alguém já está usando a versão do FastReports?

Alguém aqui já fez alguma implementação para o Banco Mercantil? Se não, eu tenho interesse em fazer por trabalhar com esse banco. Estive pesquisando alguns componentes de geração de boletos e cheguei a ver o GBBoleto, inclusive implementei a classe Mercantil nele e homologuei no banco. Agora gostaria de saber como é que está o ACBrBoleto para os bancos que estão disponíveis? Está tudo 100%? Aonde eu consigo a lista oficial dos bancos que ele atende? Para eu implementar o mesmo para gerar o boleto para o Banco Mercantil por onde devo começar? Grato.

Se tiver uma implementação disso...me avise tb...

Gostaria de saber se o ACBR já está tratando a norma técnica: 004/2011??? Fonte: http://www.spedbrasil.net/forum/topics/ ... -no04-2011 Foi divulgada a Norma Técnica 004/2011, que dispõe sobre a atualização de Schema XML da NF-e e novas regras de validação para recepção de NF-e. Prazo de entrada em vigor: A partir de 01/11/2011 em produção. A partir de 01/10/2011 em homologação para realização dos testes. Alterações no Schema XML da NFe: - O campo CEP do endereço do emitente se torna obrigatório; - Inclui novos códigos de Países(4235-Ilhas Lebuan, 4885-Ilhas Francesas); - Inclui CFOPs (1.128, 2.128 e 3.128); - Alteração de tamanho de campos (Quantidade Comercial e Tributável, DI, Número da DI, placa do veículo); - Define procedimentos para prenchimento de informações de NF-e destinadas à SUFRAMA(Valor ICMS desonerado e motivo da Desoneração). Novas Regras de validação para recepção da NF-e: - Dígito verificador do Código de Barras do Produto(Código Ean); - Validação do CPF X IE do destinatário; - Existência dos grupos de IPI e II em operações de Importação; - Validação do cálculo do Valor do Produto (Valores Unitários X Quantidade = Valor do Produto); - Estabelece valor limite da NF-e para impedir a emissão de NF-e com valores absurdos; - Validação de campos de PIS/COFINS; - CFOP - Operações Internas e Interestaduais(UF emitente X UF destinatário); Elimina Regras de validação no ambiente de Homologação: - CNPJ do destinatário deve ser igual a 9999999000191 - Não informar IE do destinatário.

Pessoal, testei o recuperador de XML aqui e achei o negócio animalesco, porém detectei um problema nele, na parte de impostos, o mesmo está puxando as informações de impostos (ICMS) de forma diferente ao do original que eu tinha aqui do fornecedor. Alguém tem idéia do que pode estar acontecendo? E como corrigir isso para podermos usar isso na prática e em modo de produção? As informações de IPI também estão vindo zeradas e divergentes. O que notei é que tipo um item com CST = 120 estava vindo com CST = 020 e BC ICMS zerada e ICMS zerados... 0 20 0 0.00 0.00 0.00 0.00

Putz...depois de umas 10hs de tentativa e erro...consegui achar e descobrir o problema. O que mais me assustou foi que realmente no compilado pelo delphi2010 o trem vai normal, porém o no delphi 2006 só funcionou depois que eu fiz o seguinte: - IExplorer - Ferramentas - Avançadas Lá no final das opções: - [ ] Verificar revogação de certificados do servidor* (desmarcar) - [ ] Verificar se há certificados revogados do editor (desmarcar) Testei e remarquei o trem, e voltou o problema, desmarquei e foi blza! Espero que ajude a turma aqui!!! Farnetani

Pessoal, inacreditável o que está acontecendo. Tenho o delphi 2006 e o ACBR nele e tenho o delphi 2010 e o ACBR nele tb. Olha que loucura, são os mesmos arquivos (fonte atualizado via svn) tanto para o componente instalado no delphi 2006 e 2010. Porém se uso a aplicação demo no delphi 2010, o processo de consulta de status passa que é uma beleza. Porém se eu uso o demo compilado pelo delphi 2006 nao vai nem a paulada, resulta: WebService Consulta Status serviço: - Inativo ou Inoperante tente novamente. - Erro no suporte a canais seguros - URL:https://nfe.fazenda.mg.gov.br/nfe2/services/NfeStatus2 - SOAPAction:http://www.portalfiscal.inf.br/nfe/wsdl/NfeStatusServico2 WebService Consulta Status serviço: O QUE SERÁ ISSO???

Pessoal, vocês poderiam me informar se o componente ACBR está apto a gerar o EFD Fiscal da forma que a legislação atual pede. O mesmo está apto para o PVA 2.03?