EMBarbosa

Você não acha que essa é uma dúvida que deveria tirar com seu contador primeiro?

Eu não lembro especificamente sobre esse comando, mas todos os comandos que iniciam com "PAFMF_" são preparados para atender os requisitos do "Menu Fiscal" do roteiro PAF-ECF. Assim, o comando pode fazer algum tratamento um pouco diferenciado quando o requisito disser algo específico sobre o comando. Em casos que não há necessidade de tratamento, os comandos iniciados com "PAFMF_" são apenas chamadas aos comandos normais. Mas visto que ficam separados pela nomenclatura facilitam pelo menos duas coisas: A distinção de qual comando usar por pessoas que estão iniciando no uso do componente/monitor e separar os comandos caso futuramente a legislação pedir algo específico sobre o comando.

O documento ainda não é oficial. É um beta 2, tanto que o site oficial do eSocial ainda não "se pronunciou". Queiram ficar atentos a esses detalhes...

Valores do quê?

Não. Não faz sentido algum. Por exemplo, se ele fizer esse pedido para alguns programadores que criptografam o arquivo inteiro, o arquivo vai corromper e será impossível ler o conteúdo de qualquer valor.

O jeito é você adicionar essas units modificadas no controle de versão do seu projeto. Daí avise a todos os programadores para fazerem o uso dessa unit ao invés de usar as que vem com o ACBr.

Não. Não me parece que você entendeu. Você tem que mudar o gt por fora do PAF. Se vai fazer diretamente no arquivo ou por meio de um outro software aí já é com você. O caso é que tem que mudar por fora do PAF.

Não esqueça de dizer que melhorias foram feitas.

Não. Ele não pode pedir isso. Mas, como eu expliquei acima, ele iria te pedir para alterar o Grande Total e você precisa saber onde exatamente está o Grande Total no arquivo. Depois vai pedir para alterar o CRO e você precisa saber onde está o CRO para alterar para o valor que ele te disser. E depois fazer o mesmo com o Número de Série. Se você não souber onde estão estes valores, você não tem como fazer o teste e daí, não pode passar. Por isso a necessidade de usar um programa diferente para alterar os valores.

O seu problema é não entender o funcionamento dos processos necessários para emitir uma NF-e. Não é no QuickReport. Favor ler o Manual de Integração conforme sugerido no primeiro tópico que o Juliomar alistou.

Para quem ainda estiver procurando o arquivo, basicamente ele dizia o seguinte: 1 - Convênio 57/95 Os registros 10, 11, 75 e 90 são necessários. Também os registros 60 (A-M-D) e 61. Outros podem ser incluídos se seu programa emitir os documentos por eles alistados e forem registros de vendas (saída) ou relacionados com elas. (Veja o convênio para saber quais são os registros. 2 - COTEPE 09/08 Os blocos 0, H e 9 são necessários. Também o C. Outros podem ser incluídos se for o caso (se seu programa emitir os documentos por eles representados e forem registros de vendas (saída) ou relacionados com elas). No Manual de Orientação do Leiaute da Escrituração Fiscal Digital – EFD ATO COTEPE ICMS Nº 09 CONFAZ, DE 18/04/2008 existe uma nota referente à obrigatoriedade de informação em cada registro apresentado. Os registros necessários ao arquivo do SPED são: "BLOCO 0": 0000 - 0001 - 0005 - 0100 - 0150 - 0175 - 0190 - 0200 - 0205 -0220 (Caso faça tal procedimento) - 0300 - 0400 - 0500 – 0990 "BLOCO C": C001 Família C100 - Incluídos os modelos 1 ou 1-A = Nota Fiscal de Sáida de Mercadorias - Código 01). Vocês terão de observar se serão emitidos alguns desses modelos de notas; se for o caso gerar os registros respectivos. Lembrando que as notas manuais são obrigatórias. Obs: Para o arquivo do Convênio 57/95, as notas fiscais do modelo acima descrito precisam ser informadas no registro tipo 50. (Família C300 - Somente para o perfil B ) = Nota Fiscal de Venda à Consumidor Modelo 2 - Código 02). Vocês terão de observar se serão emitidos alguns desses modelos de notas; se for o caso gerar os registros respectivos. Lembrando que as notas manuais são obrigatórias. Obs: Para o arquivo do Convênio 57/95, as notas fiscais do modelo acima descrito precisam ser informadas no registro tipo 61. Família C400: C400 - C405 - C420 - C425 - C490 – (C495 Somente para Bahia Perfil A e B ) - C990 BLOCO H": H001- H005 - H010 - H990 BLOCO 9": 9001 - 9900 - 9990 – 9999 Nota: O enquadramento das empresas em determinado perfil de apresentação da EFD será conforme dispuser a legislação estadual. Não havendo o enquadramento do estabelecimento em um determinado perfil, deverão ser apresentados os registros referentes ao Perfil A.

Não dá pra você exportar, alterar e importar novamente?

Bem vindo ao fórum. Esperamos que possa sanar suas dúvidas e ajudar o projeto a crescer. Visto que é novo no fórum, convido a ler e também a parte que dá orientações gerais para formular perguntas. Observe que você deve criar um tópico novo para uma dúvida nova conforme as regras. Veja neste em especial a "2.2 - Permaneça no assunto". Sobre instalar o componente, faça o download do

Não. Ainda não apareceu nenhum voluntário para implementar o bloco. Se quiser fazê-lo, nós agradecemos.

Veja o tópico: Baixe o que já foi feito Teste o que já foi feito Implemente o que não foi feito anexe as suas alterações

Então tchuck, eu posso te garantir que o código do ping via WMI está correto. Ele sozinho não é culpado pelos problemas. Então tem alguma outra coisa que junta com ele dá o problema. Algumas sugestões que me vieram a mente foram: habilitar o fulldebug do FastMM que já vem no Delphi, e verificar se ele descobre os motivos do problema; Você poderia tentar trocar o gerenciador de memória (Talvez o SynscalleMM, o ScalleMM, ou o SAPMM) habilitar o AQtime para verificar alocação de memória (que se não me engano também vem no Delphi XE5) Ver com a Embarcadero alguma sugestão para identificar o problema e solucionar. Remover os componentes da Devexpress para verificar se eles tem alguma influência

No demo funciona? O que é mostrado no log do componente?

Não entendi qual a relação entre a tag <ce> centralizar e quebrar a linha. Ao enviar a tag <ce> que era pra centralizar, acontece de quebrar a linha? Quando você envia a tag de quebrar a linha ela não acontece? Quando envia a tag para quebrar a linha ela só quebra se a tag <ce> for enviada junto?

Me parece mais um erro do compilador. Talvez alguma incompatibilidade no código com componentes antigos como o Régys disse. Talvez esteja dando erro no ping por ele fazer algum tipo de modificação nas threads principais. É possível também que dê erro por alguma incompatibilidade por causa dos skins. São muitas possibilidades, os access violations são apenas sintomas de algum problema. Algumas perguntas: Você está usando skins nessa aplicação? Está usando em algum lugar o Firemonkey? Está compilando para 64bits? Está usando algum outro gerenciador de memória que não é nativo? Está usando algum componente ou biblioteca para fazer log de erros como o EurekaLog ou MadException? Outra coisa a ser verificada é onde você faz a chamada para o ping? Está usando uma thread separada? Faz a chamada num form principal? Para cada resposta positiva no caso acima, desabilite/comente/remova para testar a influência sobre o código. Duas coisas que eu não entendi foram: Como é que o ping, que nem faz menção do EditInscEstadual.EditLabel.Caption, consegue fazer dar erro nesse componente. Em alguma parte depois do ping ele chama essa propriedade? Se o pessoal da Embarcadero identificou que o erro era neste método de fazer ping, que é sugerido pelo componente Indy, qual outro método de fazer ping eles sugerem?

Quais são os erros exatamente?

Tente usando um ping via WMI http://theroadtodelphi.wordpress.com/2011/02/02/making-a-ping-with-delphi-and-the-wmi/ EDIT: Ou use a API do Windows IcmpSendEcho

Usando algum programa provido pelo fabricante funciona?

O arquivo está muito grande, sugiro que você configure no seu cliente para gerar um arquivo por dia, ou pelo menos um arquivo por mês. Do jeito que está você logo ficará perdido... A propósito, não se preocupe com a pouca experiência com o componente. Se você começar a ler, logo vai compreender o código. Tem algum tempo que não mexo com essa parte do código, e Daruma não é minha especialidade. Mas veja o que achei: O método TACBrECFDaruma.GetDadosUltimaReducaoZ é o responsável pela montagem dos dados que você buscou. Ele chama o método TACBrECFDadosRZ.CalculaValoresVirtuais (unit ACBrECFClass.pas), que em parte faz: // Computando a Venda Líquida // if (fsVendaLiquida < 0) and (ValorVendaBruta > -1) then begin fsVendaLiquida := ValorVendaBruta ; if (CancelamentoICMS > -1) then fsVendaLiquida := fsVendaLiquida - CancelamentoICMS ; if (DescontoICMS > -1) then fsVendaLiquida := fsVendaLiquida - DescontoICMS ; if (TotalISSQN > -1) then fsVendaLiquida := fsVendaLiquida - TotalISSQN; ....(Continua)... end; Se você observar, o Total ISSQN é retirado nesse método. Bem, o valor é calculado pois ele não é retornado pelo método do ECF conforme o Help do ECF. Só que o método CalculaValoresVirtuais provavelmente é chamado por classes de outros ECFs também. Logo podemos ter algum problema aí em outros ECFs também. Aqui temos um impasse que eu particularmente não posso verificar agora e talvez nem seja a melhor pessoa indicada. Talvez algum dos outros programadores que tem mais conhecimento dos ECFs Daruma poderão verificar a melhor opção. A forma como está atualmente me parece incorreta, e não bate com os dados da Redução Z impressa.

Realmente, pelo ATO COTEPE 85/01, que você citou, eles tem razão e Venda Líquida não inclui ISSQN. Isso mudou para os novos ECFs produzidos em conformidade com o ATO COTEPE 09/09, pois este tem outra especificação (ATO COTEPE 16/09). Neste novo, Venda Líquida diária inclui os valores de ISSQN que não foram cancelados, isentos ou não incidentes. De qualquer maneira, como o ECF modelo fs700 está em conformidade com o convênio antigo, o código estaria incorreto. Qual o método que você chamou para perceber o erro? Ainda tem o log dos dados retornados? Chegou a corrigir o código?

Onde diz que as vendas registradas como imposto ISSQN não devem estar na venda líquida?