Daniel Simoes

Vou precisar de um FeedBack sobre o Sleep.. para saber se modifico no SVN... Se resolveu, se ficou muito lento, etc...

Baixa do Sefaz e copia pra lá...

Apenas copie o Schema que falta para a pasta de Schemas

Nem todas as Units iniciam com "acbr"... Exemplo da Unit que você mesmo citou, da synapse use o script apagaacbr.bat para remover todas as Units do HD

Notei alguns bugs nessa rotina... Ja estou trabalhando nisso...

Não vejo isso como um problema do ACBr... Afinal o ACBrInstall funciona normalmente... Deve ser algo no seu ambiente... Se desejar reportar modificações no para os Packages fique a vontade

Estou investigando o caso... Atualmente, vários dos desenvolvedores do ACBr estão atuando no Fortes CE ( eu inclusive )

Qual modelo você está usando ?

É algo no Fortes Report... pode ser difícil de debugar... Se você atribuir o numero de cópias por código e não efetuar o preview.. deve funcionar...

Não é um erro do ACBr... é uma falha de validação de Schema...(a mensagem é bem clara) OpenSSL ou CAPICOM ? Os Schemas estão atualizados ?

O Envio do XML do SAT não depende do ACBr... isso é feito em background pelo próprio SAT Muito provavelmente o SEFAZ de homologação está com problemas... Extraia o Log do SAT e veja os comandos que ele tentou... o A.V. provavelmente ocorre porque você selecionou o modelo errado (STDCALL ou CDECL)

Parece que você está usando uma versão antiga da DLL da Sweda... Ou ainda, a DLL da Sweda depende de outras DLLs, que ela não está encontrando... Experimente copiar TODAS as DLLs da Sweda para a mesma pasta do seu aplicativo...

Comparei as Units com o Trunk2 e notei muita diferenças... o que me leva a crer que essas Units foram feitas para o Trunk... Poderia por favor avaliar se o problema ainda ocorre no Trunk2 ? Se SIM, favor providenciar Units modificadas com a última versão do Trunk2

libCapicomDelphiSoap usa a Indy... e libCapicom usa uma implementação do ACBr semelhante ao THttpReqResp da Indy... estranho... a implementação da Indy, em teoria, deveria ser a mais confiável...

Se você atribuir o número de cópias na propriedade do DANFE, funciona, correto ?

Tente usar ACBrNFe1.Configuracoes.Geral.SSLLib := libCapicomDelphiSoap;

Ricardo, Antes o ACBrSATExtratoEscPos, fixava a largura em 2... por isso não requeria a configuração... porém, tive reports de que alguns outros modelos não gostavam dessa configuração.... Então agora, ele espera que o usuário efetue a configuração e usa o que estiver configurado... Provavelmente o valor (0), nesse modelo, está usando internamente uma largura maior do que 2...

ahh.. você está falando do Trunk... nós estamos usando o Trunk2... Não estou mais trabalhando no "Trunk"... você pode editar o DFM e remover a propriedade com problema...

Como você já tentou de tudo e não funcionou... desconfie dessa informação... abra você mesmo o SGRSAT e verifique, experimente ainda, apagar essa associação e criar uma nova...

Nos meus testes está tudo ok... Dê mais detalhes para chegar no problema... Forneça um passo a passo, usando o Demo do ACBrNFe...

como você fez para: "vc pede para imprimir 2 paginas" ? modificou a propriedade no componente ? Usou o visualizador e clicou em imprimir ? De um passo a passo detalhado... se possível, grave um video...

Qual é exatamente o problema ? A resposta do Fisco não vem a autorização ?

Pode ser que você tenha modificado algo no Demo, compare com o TortoiseSVN... Use apenas o botão "Imprimir DANFE", e leia um XML já existente

A modificação estará disponível na próxima compilação semanal

Como reproduzir o problema, usando o Demo do ACBrNFe ?