EMBarbosa

Não era necessário ter apagado a pasta do ACBr se não havia conflitos. Mas que bom que funcionou. Obrigado pelo retorno.

Está compatível sim. Seus arquivos é que estão com problema de conflitos. Veja o erro: Copyright (c) 1983,2002 Borland Software Corporation C:\Delphi7\ACBr\Fontes\ACBrSerial\ACBrECF.pas(411) Error: 'END' expected but '<' found Não existe o caracter '<' na linha 411 do arquivo no SVN. Faça o Download novamente.

É só uma possibilidade, mas pode ser que o arquivo não caia neste filtro. Talvez seja um arquivo que não possui a versão no nome... Vá no código fonte aonde acontece o erro que você reportou, segure Ctrl e clique no nome da propriedade. Veja se consegue abrir o arquivo. Se não conseguir, faça uma busca no Windows por arquivos contendo a propriedade mencionada no erro. Daí você deve encontrar o tal arquivo.

Aí a busca não vai mais ser exata. Ela vai ser case-insensitive, o que é totalmente diferente.

Conflito de versões. O código está procurando uma propriedade que não foi encontrada. O mais comum é que há mais de um arquivo .pas ou .dcu ou .bpl com mesmo nome, mas em pastas diferentes, está acessível ao compilador do Delphi. O compilador está se confundindo...

Você tem certeza que não existe o arquivo windows.pas em lugar nenhum? Será que não é problema de caminho ou do Linux ser case-sensitive?

Entre Firebird e o quê?

Você está vendendo os produtos separadamente? Exemplo: Venda 5 macarrão por 1,00 e depois venda 1 macarrão por 1,50. É assim que está fazendo?

[Reservado para orientações de implementações específicas]

Lista de campos e registros alterados: SPED PIS/COFINS (EFD Contribuições). Nota: substitua abaixo o asterisco * por PIS ou COFINS conforme o registro. Registros C191 e C195 campos VL_DESC, VL_BC_*, ALIQ_*, QUANT_BC_*, ALIQ_*_QUANT, VL_* Registros C381 e C385 campos VL_BC_*, ALIQ_*, QUANT_BC_*, ALIQ_*_QUANT, VL_* Registros C481 e C485 campos VL_BC_*, ALIQ_*, QUANT_BC_*, ALIQ_*_QUANT, VL_* Registros C491 e C495 campos VL_BC_*, ALIQ_*, QUANT_BC_*, ALIQ_*_QUANT, VL_* Registros D350 campos VL_BC_*, ALIQ_*, QUANT_BC_*, ALIQ_*_QUANT, VL_* Vários campos dos Registros M100, M105, M210, M500, M505, M610 Registro C170 campos ALIQ_*_PERC, QUANT_BC_*, ALIQ_*_R, VL_* SPED Fiscal (EFD ICMS/IPI) Ainda em análise Ainda em análise

Trabalhos neste sentido foram retomados, vejam:

Estamos fazendo modificações nos componentes SPED que podem resultar em necessidade de corrigirem seu código. Por isso estamos avisando com antecedência para você poder estar pronto. As alterações estão previstas para ir para o SVN na primeira quinzena de Janeiro de 2015 já estão no SVN. Há algum tempo temos um bug em certos registros do SPED que não puderam ser resolvidos. O problema é devido a alguns campos que precisam ser gerados com valores numéricos incluindo '0' (zero), mas também precisam aceitar o valor vazio ( e mais ). O componente não consegue atualmente tratar esses casos de forma satisfatória e as alterações são para corrigir isso. Infelizmente, estas alterações podem quebrar a compatibilidade do seu código atual. "Não!!! Não façam isso com meu código!!!" - disse o programador preguiçoso. Em primeiro lugar não é seu código. É nosso! Além disso, como dito acima, também não estamos tão felizes assim. Mas ou fazemos a alteração, ou não vamos atender a necessidade de todos nem a legislação atual. Preferimos qualidade e confiabilidade. "Mas o que vai mudar?" - disse o programador curioso. Resumindo a alteração: Estamos modificando o tipo destes campos para Variant ao invés de um tipo numérico (Currency, Double, extended, etc...). Assim, quando você precisar gerar um valor vazio no campo, bastará passar Null (variant nula) para o campo. Se quiser que seja gerado com '0' (zero), bastará passar zero para o campo. Sim, isso já foi e não é um dejavu. Alguns registros já funcionam assim, como por exemplo os Registros C181 e C185. "Nenhuma chance de eu não precisar fazer nada?" - disse o programador esperançoso. Se você não utilizar os registros mencionados você não vai precisar fazer nada. A lista dos registros estão no deste tópico. "E se eu não quiser mexer com isso agora?" - disse o programador apertado com os prazos. Bom, você pode ficar sem atualizar seus componentes SPED. Mas que fique claro que não recomendamos isso e que você talvez não consiga gerar os arquivos 100%. Daí você talvez pense: "Ok, eu quero resolver isso. Mas queria saber onde eu posso ter problemas, e o que fazer para corrigi-los." Achei que não ia perguntar. O caso é que os componentes não vão mais tentar adivinhar se o campo ficará vazio ou não vazio quando o valor dele for zero. Você é quem deverá definir isso. Logo, se você está sempre confiando que quando passar zero o componente vai tornar os campos vazios por você, então você pode ter problemas nestes casos. Veja um exemplo: Na EFD Contribuições (SPED PIS/COFINS), quando você gera registros C191, existem os campos VL_BC_PIS, ALIQ_PIS, QUANT_BC_PIS e ALIQ_PIS_QUANT. Normalmente, você vai preencher os dois primeiros. Ao preencher os dois primeiros você deve fazer com que os campos QUANT_BC_PIS e ALIQ_PIS_QUANT fiquem vazios. O código atual talvez seja assim: RegistroC181.VL_BC_PIS := 100; RegistroC181.ALIQ_PIS := 1.65; RegistroC181.QUANT_BC_PIS := 0; RegistroC181.ALIQ_PIS_QUANT := 0; Você vai ter que alterar para: RegistroC181.VL_BC_PIS := 100; RegistroC181.ALIQ_PIS := 1.65; RegistroC181.QUANT_BC_PIS := Null; RegistroC181.ALIQ_PIS_QUANT := Null; Mas talvez, você seja um dos que desenvolvem software para fabricantes ou importadores de combustíveis e de bebidas frias (água, cerveja, refrigerantes) que tenham optado por apurar as contribuições sociais com base na quantidade de produto vendida. Neste caso, você vai querer preencher os campos posteriores e deixar os dois primeiros vazios. Algo assim: RegistroC181.VL_BC_PIS := Null; RegistroC181.ALIQ_PIS := Null; RegistroC181.QUANT_BC_PIS := 10; RegistroC181.ALIQ_PIS_QUANT := 0.1; Isso foi apenas um exemplo. Mas, via de regra, o que você de prestar atenção é: O código gerava vazio pra você e você quer que continue assim? Então atribua Null. "Mas e os eventos? Não tinha alguns eventos para resolver esse problema?" Hmmm!!! Temos um espertinho aqui! O problema dos registros com eventos (C481, C485, C491, C495), é que o evento é gerado na hora de escrever o arquivo e não na hora de alimentar o componente. Por isso, você já não tem acesso ao banco de dados. Assim, pode ser preciso consultar novamente ao banco de dados para decidir quais campos vão ser preenchidos ou deixados vazios. Isso pode ser um problema muito grande e até insustentável dependendo do tamanho do seu banco de dados e do período gerado. Fora que são mais conexões desnecessárias ao BD. Assim, os eventos estão sendo considerados obsoletos (deprecated). Mais cedo ou mais tarde eles serão removidos. Para evitar maiores problemas, o código dos eventos a princípio vão continuar funcionando. Quer dizer que, se você está utilizando os eventos e eles estão lhe atendendo, você pode decidir não mexer nessa parte do código. Mas incentivamos você a remover os eventos e fazer os tratamentos conforme acima sugerido para os outros registros assim que as alterações forem postadas no SVN. Veja abaixo onde as modificações estão sendo feitas primeiro e analise ali se seu código precisa ser modificado. Apenas atente que isso é apenas os primeiros lugares onde vão acontecer as modificações. Mais lugares vão ser alterados sempre que percebemos que o código atual não pode atender a necessidade e legislação que afeta todos os nossos usuários. Vamos tentar manter a lista abaixo atualizada.

Você não está confundindo '4' com '04'?

O endereço do repositório é "svn://svn.code.sf.net/p/acbr/code/". Para mais informações veja Uma possível causa é que talvez você tenha esse arquivo em mais de algum lugar, como por exemplo numa pasta do seu projeto. Chegou a verificar isso? EDIT: Não é que enquanto eu digitava você resolveu?

Tradução do erro: "Não foi possível carregar a biblioteca padrão xmlsec-crypto. Tenha certeza que você a tem instalado e verifique a variável de ambiente de caminho para bibliotecas compartilhdas (LD_LIBRARY_PATH)." Em outras palavras, verifique se as dlls do openSSL estão na pasta do seu executável ou acessíveis em algum outro lugar.

Acho que não vai conseguir baixar o Delphi IDE Fix Pack, pois parece que o site oficial do Andy está fora do ar... Se baixar do site oficial pode ficar tranquilo que não é vírus. Mas como faz modificações binárias, alguns antivirus vão detectar como um falso positivo e vão lhe alertar. Um artigo na edn (link aqui) sugere algumas alternativas, como renomear o arquivo toda vez antes de abrir a IDE e rodar um outro utilitário open source (um post blog do criador está aqui) feito exatamente para contornar isso. Mas acho que o mais completo é a pergunta e as respostas no StackOverflow aqui.

O certo seria você mostrar pra eles a regra do PAF-ECF e perguntar a eles onde está a informação que você pode fazer diferente. Se eles não puderem ou não quiserem lhe informar, peça um documento assinado por eles assumindo a responsabilidade pela implementação.

Visto que não temos os direitos de distribuição sobre o livro, não seria correto fazer isso aqui no fórum. Favor atentar no nosso fórum: 5.1 - Respeite os direitos autorais - Não há objeção de se postar algum trecho de algo para desenvolver o seu post. No entanto, em vez de publicar em sua totalidade um texto de outra pessoa, coloque um link para o conteúdo. A não ser, é claro, que você seja o detentor ou tenha a permissão do detentor dos direitos autorais. 5.2 - Nada de pirataria - É proibido fornecer ou pedir informações sobre como obter ou fornecer ilegalmente qualquer coisa como software ("warez", "Crackz"), música, etc.

Ah, obrigado. Mas o problema que você citou já foi corrigido juntamente com outros problemas semelhantes conforme os posts acima e no tópico que eu mencionei antes. Se tiver outros casos no BD que não estejam sendo resolvidos pelo código atual, cujo commit foi feito hoje, aí sim eu gostaria de ver os valores. Mas não precisa do BD. Só dos valores mesmo. Ah, e obrigado por ter reportado o erro.

Não achei a documentação deste Fetch Rows, mas acho que tanto ele quanto o packed record não é o exatamente o que você está pensando. Não é um limite de quantidade de registros. mas quantidade de registros por vez... Quando eu disse query, eu não quero dizer TQuery ou algum componente semelhante, mas a consulta ao banco de dados composta do Select e seus parâmetros. Então a ideia seria um where para limitar a quantidade de registros que devem ser retornados já que você possui o FK.

Veja o que é recomendado a se fazer com o FireDAC. Desde que você apenas carregue poucos registros por vez, você não vai ter muitos problemas.

No contexto apresentado, não foi detectado nenhum problema. Você tem algum exemplo em que pode gerar problema?

Esse assunto foi resolvido e enviado ao SVN hoje utilizando outro método. Mais informações sobre a correção desse problema no seguinte tópico: Estou fechando esse tópico para não haver duplicação de informações. Por favor, continuem no tópico acima.

Para não poluir mais esse tópico com o assunto de arredondamento, postei uma explicação para eu não mexer em nada sobre isso neste