EMBarbosa

Faça debug no código e verifique em que momento acontece a mudança de 9,19 para 9,18.

Estou achando muito estranho o tipo Extended não conseguir comportar uma precisão tão pequena nos cálculos. A princípio ele deveria ter um suporte maior a números significativos que o tipo Double. Buffon, a mudança para o tipo Extended foi para que pudesse ser permitido alguns casos onde havia necessidade de até 6 casas decimais. Como sugerido, você pesquisou aqui no fórum para encontrar o tópico sobre a mudança? Se a mudança para Double não afetar o problema das 6 casas decimais, acho que não haverá algum problema. Estou começando a achar que deveríamos adicionar alguns testes unitários nessas funções do SPED. o.o''

Como todos podem ver temos hoje vários componentes ACBr e emitimos cupom fiscal, NF-e, CT-e, NFS-e, MDF-e entre vários outros! Gostaríamos de uma forma de responder melhor as expectativas da comunidade com respeito a tempo e qualidade nas impressões que temos hoje como DANFe, DACTe, DANFSe, DAMDFe, etc. Para trazer esse trabalho de maior qualidade, pensamos em direcionar a emissão destas impressões para um único gerenciador de relatórios. A razão direcionar para um único é simples: Com todos os desenvolvedores trabalhando focados em um único ponto, podemos direcionar os esforços e deixar os relatórios com todas as opções e particularidades possíveis de cada documento impresso, não precisando repetir isso para cada um dos gerenciadores hoje existentes dentro de todo o projeto. A escolha do momento é o FortesReport, e se dá pelo simples motivo de ser compatível com o Delphi e Lazarus bem como ser de código aberto! Uma outra opção seria ter FortesReport e FastReport. O FastReport por ser a ferramenta oficial do Delphi e muito bem aceito na comunidade Delphi. Mas o FastReport por enquanto ainda é beta no Lazarus (http://www.fast-report.com/pt/product/fast-report-lazarus/). Gostaríamos dos votos da comunidade antes de tomarmos uma decisão definitiva se é que vamos alterar alguma coisa. Então a enquete é para saber a opinião de todos para que exista somente um ACBrDANFe, ACBrDACTe, ACBrDAMDFe, ACBrDANFSe, ACBrGNREGuia somente em FortesReport mas, neste caso com, todas as opções possíveis (por exemplo modo paisagem e retrato).

De acordo com os perfis atualmente em vigor , ele só não é exigido no Perfil "X" que é adotado única e exclusivamente por MG. No Rio de Janeiro, que parece ser seu estado, ele está marcado como exigido (Perfil "W"). Assim, ou você faz, ou pode ser que a SEFAZ do RJ recuse o cadastro do seu PAF-ECF.

A propósito, esse pacote "gbCob5.dpk" não parece fazer parte do projeto ACBr. Assumindo que você fez os downloads usando o svn da pasta trunk, você deve fazer as instalações dos pacotes que estão na pasta \pacotes\Delphi

Queiram ver o outro tópico, onde o usuário Edson.pol está tentando reunir os interessados no RecuperarXML, e o código atualizado pode ser encontrado no SourceForge.

Você deve instalar apenas os pacotes que vai utilizar e apenas os que são suportados pelo seu ambiente de desenvolvimento. Esse pacote por exemplo parece requerer o QuickReport numa versão específica. Se você não tiver instalado, não vai mesmo instalar.

Veja o arquivo LEIAME.TXT. Ele vai te dar uma ideia de como fazer a instalação manual.

Pois é, achei estranho o site do TechCrunch ser do início do mês. Mas já que o David I linkou pra página deles, acho que agora tá liberado. E realmente isso que você disse já está oficialmente disponível, pelo menos em inglês. Daí acho que não cai mais sob o NDA. No entanto, pode ser que alguma coisa que eles lhe revelaram por e-mail ainda esteja sob o NDA. Sobre o AppMethod, vamos aguardar e ver o que vai dar. Eu particularmente gostei do wiki.

Olá Régys, Algumas das informações já saíram de forma oficial. Saiu no techcrunch no início do mês e está no ar até hoje, veja aqui. E mais recentemente, saiu o lançamento do site oficial do David Intersimone. Mas quem recebeu as informações diretamente da Embarcadero, provavelmente ainda está sob o NDA. Você pode obter muita informação que já está publicada no site, que aponta pro wiki, ou no fórum da própria Embarcadero.

Olá Edson, Primeiro gostaria de agradecer sua compreensão e o fato de respeitar a decisão de não incluirmos mais o RecuperarXML no projeto ACBr. Também gostaria de elogiar você por tomar atitude de fazer alguma coisa por algo que lhe é importante. Muitos parecem apenas estar dispostos a reclamar que não aparece alguém pra fazer alguma coisa. Eu costumo dizer que você pode ser o alguém. Em segundo lugar, parece que o pessoal que reclama esquece que este projeto nasceu aqui. Num certo momento decidimos que não seria bom pra nós continuá-lo e isso deveria ser respeitado. Não deveria importar o motivo da decisão, mas mesmo assim alguns dos moderadores já explicaram. A questão é que o projeto continuou aberto e qualquer um poderia pegar de onde parou e continuar. Nem mesmo trancamos todos os tópicos sobre o assunto achando que isso talvez pudesse passar a impressão errada. Agora, devido a confusão, já estamos pensando em fazer o contrário... Então, como sugestão, para evitar qualquer desgaste ou confusão maior, estou sugerindo que você faça as seguintes alterações no projeto: Remova a referência ao site do fórum do ACBr nas telas do programa. Ponha os links para a página nova que você criou no SourceForge. Isso vai ajudar a concentrar todos que querem ajudar lá e você poderá ter mais retorno. Na tela de "sobre o programa" e nos comentários do código fonte, adicione uma explicação que você está usando o código baseado num projeto que foi descontinuado pelo ACBr. Isso pode ajudar outros a perceber que a versão que está no seu projeto é atualizada e talvez assim queiram lhe ajudar. Dê uma identidade nova ao projeto. Crie uma nova versão, novo nome, novos ícones, sei lá... alguma coisa assim. profit Acho que é isso.

Ah. Compreendi. Uma coisa é o problema de arredondamento, outra coisa é a exibição de 3 casas decimais.

Sim, é normal. Estes registros são obrigatórios. Você deve ler a legislação que explica o layout. O validador (PVA) informa os locais onde aconteceram os erros quando o erro não é na estrutura. Antes de imprimir existe um checkbox que você marca e depois aperta o botão "Exibir" para que ele exiba os erros. Veja abaixo:

Se acontece em TODOS os forms então, ou seu projeto corrompeu todo (o que seria muito improvável), ou você provavelmente encontrou um bug crítico. Eu tentaria abrir o projeto em outra máquina ou com outra versão do Delphi só para ter certeza. E já que você levantou a possibilidade de ser um erro pela quantidade de forms, outra opção é criar um novo projeto e ir adicionando os forms um a um, salvando e fechando o projeto periodicamente até que você veja qual form que causou o problema.

GET (YouTube) Based -> XML Based -> http://edn.embarcadero.com/article/10443 Web-broker Based -> http://delphi.about.com/library/bluc/text/uc060901a.htm "Hello World" Based -> http://rosettacode.org/wiki/Hello_world/Web_server#Delphi CGI Português based -> http://www.linhadecodigo.com.br/artigo/750/delphi-desenvolvendo-um-web-server.aspx LMGFY Based -> http://bit.ly/1nJJanx

O erro é em um form específico? Em caso afirmativo, pode ser algum erro no arquivo ".dfm" dele. Este arquivo costuma ser salvo como texto. Tente verificar se há algo de errado nele. Caso não for possível, creio que só o suporte da Embarcadero possa ajudar.

Mas e a correção? Ainda é necessária para exibir as 3 casas decimais no campo de quantidade?

Isso significa que você está gerando registros 60D mas não criou antes o registro 60M para este dia.

Ah sim, faz sentido. Creio que esta seja a correção adequada. Eu não tenho aqui um ECF Sweda para testar nem tenho feito alterações na classe SwedaSTX. Você poderia fazer a alteração e anexar aqui no fórum para que outro desenvolvedor possa dar uma olhada e outros usuários possam testar?

Pode ser um bug no firmware mesmo, mas daí não caberia alterações no componente. O melhor seria atualizar o firmware. Contudo, precisa-se verificar com o fabricante se este modelo realmente suporta a propriedade ou se ele precisa de algum tratamento diferenciado. Talvez no manual de comunicação serial você encontre essa informação. No caso dele exigir um tratamento diferenciado, então mudamos o comportamento na classe para este modelo específico como você sugeriu. Quando os modelos exigem tratamento específico, fazemos isto no código. É normal. Mas quando o problema é do firmware, apesar de podermos tratar no código, só o fazemos no último caso. Devemos programar com o funcionamento correto do equipamento em mente e não para consertar bugs dos fabricantes (salvo se não houver outra escolha).

Pois então, veja a linha apontada pelo erro. Qual o código do produto nesta linha? Agora procure no restante do arquivo se este produto existe em algum registro 54, 57, 60D, 74, 77, 86... Você provavelmente não vai encontrar, então precisa saber: Por que foi gerado o registro 75 para ele?

Se o ACBrECF já consulta o ECF para saber a quantidade de casas antes de fazer a venda, seria melhor consertar o retorno da classe (método 3 que você descreveu). Digo isso pelos trechos que você escreveu aqui, com grifo meu: Logo, o erro seria no retorno da impressora. Afinal, se o ECF está configurado para 3 casas, ele deveria retornar 3 casas.

Modifiquei seu post para adicionar a tag CODE. Além disso, faltou postar a mensagem de erro completa.

Não existem métodos de gerar os registros do Sintegra pelo ECF. A legislação do PAF-ECF exige que seja gerado pelo banco de dados do software. Quem cumpre o PAF-ECF utiliza os dados do banco de dados e o componente ACBrSintegra para montar o layout do arquivo. Caso seu estado não tenha exigência do PAF-ECF e você deseje gerar estes arquivos com base nos dados do ECF, então você deve utilizar a dll do fabricante para esse método específico.