AlexandreADC

Você está certo, visto que o "String" em versões anteriores ao Delphi 2007 são Ansi... Então por quem fez, qual foi o objetivo de declarar essas variáveis em AnsiString?

Usei o Flex e foi a ferramenta que mais me identifiquei. Olhem: http://www.flexerp.com.br/sistema.cfm

Eu não usaria IntraWeb... Usei uma vez e me decepcionei totalmente (desculpe aos desenvolvedores dele). Eu postei no meu blog algumas conclusões sobre o uso: http://extremeprogramming.wordpress.com ... eb-delphi/ E enfatizo os bugs que ele tem, são erros que estressam MUITO! Visual até o TMS pode ajudar, mas prepare-se que cada navegador vai ter uma aparência diferente! :/

O TStringList foi feito pra Unicode e não pra AnsiString apartir do Delphi 2009*... Ele teria que converter mesmo assim ao adicionar a linha... E todas as properties texto de todos os Blocos estão como String, então voltaríamos a estaca zero haha O LFILL, RFILL e semelhantes usam funções dentro dele que trabalham com String também... Eu acho que se fizer isso vai aumentar ainda mais as conversões implícitas de AnsiString pra String e vice-versa...

Além de diminuir a geração do arquivo de 4h para 10 minutos, não gerou mais os pontos de interrogação dentro do arquivo... Fiz em 2 Blocos apenas, mas já deu uma grande diferença pra mim... Se usassem diretivas como essa em todo ACBr, ia diminuir os milhares de warnings de conversão de ANSI para Unicode... Está aqui o arquivo: ACBrECDBloco_I_Class.pas

Só acontece neste cliente que tem esse volume de lançamentos... Uso o Delphi XE, cada vez que gero o arquivo, ele aparece as interrogações em pontos diferentes... Como falei, debugar uma geração que pode levar horas sem breakpoints, imagina com... Pode ser sim erro em Unicode, já que a declaração da procedure está function TBloco_I.WriteRegistroI200: AnsiString; e o LFill está function TACBrTXTClass.LFill(Value: TDateTime; Mask: String = 'ddmmyyyy'): String; O Delphi fica convertendo automático toda hora e em algum momento deve estar se perdendo... (eu imagino que seja) Delphi 7 não usa Unicode né?! Podiam colocar lá, algo semelhante ao feito no SPED PIS/COFINS: Diretivas de compilação! hehe Tanto que dias atrás tive problemas com a tabela de caracteres da mensagem de erro retornada pelos componentes do Sped Fiscal e Contábil que usam ANSI, colocando diretivas lá: {$IFDEF UNICODE} resolveria nossos problemas... Nem vou querer iniciar discussão sobre o uso do Delphi 7 ou dos posteriores, porque sou teimoso demais pra discutir rsrsrs Vou modificar aqui o componente colocando no bloco I as diretivas e gerar e verificar...

Boa tarde pessoal, nosso cliente está tentando gerar o arquivo do SPED Contábil, existem tantas movimentações em 2011 que o arquivo acaba ficando com quase 600.000 linhas e mais que 30Mb... E quando há um volume assim há algumas anomalias que pelo Debug eu iria demorar anos pra encontrar, pois começam a aparecer depois de 400.000 linhas do arquivo... Olhe alguns exemplos de linhas que ele gera: |I250|1220||4714,20|C?||NF: 01672? Com?anh?a Nacional de Abastecimento CONAB|| |I200|?036?2|09112?11|?850,00|?| |I250|7869||1850,00|D|||CTRC 000776 ? Fe?tipar Fertiliza?tes?do Parana Ltda|| |I250|6820||1850,00|C?||CTRC ?00776 Fertipa? Fertilizantes do Parana Ltda|| |I?00|503693|31102011|3448?6,21|N| |I250|1220||344866,21|D|||NF: 0031'1 † Co?pan?ia Naci?nal de Abastecimento CONAB|| |I250|1598||3?486?,21|C||?NF: 003?21 Companhia Nacional de Abastecimento CONAB?| |I200|503694?311?2011|7566,00|N| |I250|1220||7566,0?|D|||NFl 00?074 ?omp?nhi? Nacional de Abastecimento CONAB|| |I250|1?98||7566,00|C|||NF: 003074 Companhia Nacional de Abastecimento CONAB|| como visto acima, raras as vezes ele chega até a ficar no lugar do "2" do I200 (deixando I?00), e em algumas vezes, a mesma String (Companhia Nacional de Abastecimento CONAB), apresenta alguns caracteres especiais no meio, ou não. Estamos preocupados porque dá mais erros no validador do que poderíamos alterar manualmente no arquivo... Alguém tem alguma ideia como resolver?

Uso o Delphi XE, update 2. Báaa, incompatibilidade de AnsiString com Unicode... Eu estava fazendo um Application.Messagebox com a mensagem retornada, e resultava nisso, converti a mensagem: "Mensagem := AnsiToUtf8(MsnError);" e resolveu... Fica aí a dica pra quem tenha passado por isso!

Bom dia, eu sei que não está em chinês, mas a mensagem de erro está usando uma tabela de caracteres errada. Tanto no SPED Fiscal quanto no Contábil, no PIS/COFINS não deu... Talvez porque não use as mesmas rotinas... Ele cai no procedure TACBrTXTClass.Check(Condicao: Boolean; const Msg: String); begin if not Condicao then AssignError(Msg); end; E quando vai dar a mensagem de erro no AssignError ele deve fazer umas conversões erradas de AnsiString pra Unicode...

Boa tarde, gostaria de saber se o ACBr irá preencher estes campos automaticamente dependendo da quantidade de registros dentro do Bloco 1 ou deverei preencher esses dados manualmente? Obrigado.

O Pacote CAPICOM sempre foi instalado. Aconteceu hoje novamente em um cliente, instalamos as DLL's do CAPICOM, mas não resolveu... Pegamos essa mesma nota, colocamos em outro computador, com o mesmo certificado digital e ele foi... Alguma outra sugestão?

Você tem razão, as dll's do CAPICOM podem não estar sendo registradas na máquina dos usuários. Vou fazer um levantamento e verificar se o erro foi corrigido.

Boa tarde pessoal, há meses que estamos como esse problema e não conseguimos identificar o problema. Porque em alguns computadores/notas acontece, em outras não. No mesmo computador, com 2 notas diferentes, uma vai e outra não. E a nota que não estava indo em um computador, vai em outro. O problema está no envio para a SEFAZ, parece que em alguns casos ela não retorna nada. Quando eu troco pro emissor gratuito ela vai sem problemas... Quando ele executa o: ReqResp.Execute(Acao.Text, Stream); Ele não retorna nenhuma mensagem no FRetornoWS := TiraAcentos(ParseText(StrStream.DataString, True)); Vem retorno vazio, mas não é só no envio, na consulta também não retorna nada... Normalmente são clientes de SC e MS. Alguém enfrenta o mesmo problema? OBS: Não é Firewall nem antivírus, nem problemas na rede.

Não que a falta desta alteração me afete, mas uma sugestão que deixo é que façam alternativas para antecipar a troca no cliente. Porque compilar e instalar em 1 mesmo dia as vezes é complicado... Se fosse feito alguma diretiva de compilação, para que quem quer antecipar a compilação da BPL assim como foi feito a versão 1.04 do CTe, acho que agradaria a todos.

Acredito que o leiaute em si não tenha mudado, mas sim as validações, as regras e orientações.

Existe uma Tag chamada locEnt do Destinatário que serve exatamente para este propósito, o qual só deverá ser informado caso o endereço de entrega for diferente do destinatário.

Descomente o {$DEFINE QReport_PDF} do ACBr.inc para que gere o PDF.

Que maravilha! Obrigado Italo!

Sugiro que comitem esta configuração do ACBR.inc para o SVN, porque, afinal de contas, quem tem a versão 1.03 não conseguirá enviar mesmo...

Entendo... Agradeço pela rápida resposta e explicação sobre o assunto Um grande abraço!

Olá pessoa, não sei o objetivo desta mudança, mas está me trazendo muito transtorno... Todos os registros filhos, a partir de certo momento começaram a necessitar de um parâmetro na criação, ex: function TRegistroC110List.New(AOwner: TRegistroC100): TRegistroC110; begin Result := TRegistroC110.Create(AOwner); Add(Result); end; Onde teria que passar o AOwner... Poxa, se eu faço "with RegistroC100.RegistroC110.New do begin" ele deveria implicitamente passar o Ownder dele como o RegistroC100, já que ele nada mais é do que uma propriedade do Registro C100. Ele tava funcionando certinho, zero bala até essa alteração, no qual eu teria que mudar todo meu código... Também não encontrei resultados para explicar o motivo desta alteração... Alguém poderia me explicar? Att

Obrigado Ítalo, você está certo. Na minha aplicação esta linha estava comentada, pois na época possivelmente estava faltando no componente...

Amigos, quando coloco indicador do Simples Nacional, ele não deveria preencher a Situação Tributária. Mas na impressão tem. E lá fica como: 00- Prestação Sujeito a Tributação Normal do ICMS. No qual regras como: http://www.sefaz.ba.gov.br/nfen/portal/ ... cional.pdf Indicam que deveria aparecer como ISENTO ou por Situação Tributária E como o CT-e não trata a Substituição Tributária, acredito que o correto seria ISENTO. Confere o que eu disse? Obrigado!

Olá caros amigos parceiros e desenvolvedores do CT-e Venho reparado nos nossos clientes, que por falta de preenchimento dos campos, as vezes o validador do CT-e valida como errados campos que estão certos... Tenho como o último caso aqui, quando não é colocado nenhuma NF para o Remetente, quando vai validar ele dá a seguinte mensagem: Falha na validação dos dados do Conhecimento 1 De acordo com o DTD ou o esquema, o conteúdo do elemento '{http://www.portalfiscal.inf.br/cte}rem''>http://www.portalfiscal.inf.br/cte}rem' está incompleto. Esperado: {http://www.portalfiscal.inf.br/cte}email,'>http://www.portalfiscal.inf.br/cte}email, {http://www.portalfiscal.inf.br/cte}infNF,'>http://www.portalfiscal.inf.br/cte}infNF, {http://www.portalfiscal.inf.br/cte}in....'>http://www.portalfiscal.inf.br/cte}in.... Quando eu preencho uma NF, ele valida OK, ou seja, o "email" está perdido ali... Este é somente 1 caso... Já vi outros em que ao não encontrar certa informação do veículo, ele dizia que não estava validando a placa, que nem fazia parte da história... Outra coisa que eu sugiro, é tirar o {http://www.portalfiscal.inf.br/cte} e aumentar o tamanho máximo da mensagem... Se possível colocar um parênteses no final do nome da TAG, com uma descrição dela. Eu entendo que isso poderia fazer facilmente nas nossas aplicações comerciais e que a validação teria que ser nela. Mas é uma sugestão para o ACBR, já que eu mesmo uma vez implementei validações sobre os campos e vi que se eu tiver que trocar as validações a cada layout novo do CT-e, perde-se muito tempo além de adaptar a aplicação para o novo Layout. Grato, Alexandre De Carli

Lembre que o ID da NF-e deve ser informado sem o prefixo "NFe". Um cliente meu também estava reclamando quanto a isso, mas ele estava colando a chave com o NFe e o campo cortava os últimos 3 números, e na hora de alimentar o componente ele tirava o "NFe", ficando assim o ID menor do que 44 dígitos... Espero ter ajudado...