WesleyAS

O erro 964 era pra estar desativado já, mas o 744 ainda não.

O erro é apenas na NFC-e mesmo. Não tenho o contato direto dele, mas nosso contador conseguiu num grupo nacional de contabilidade.

Aparentemente foi erro da SEFAZ aqui em MT, inclusive nos informaram que vão desativar a regra 969.

Achei o maldito erro. No nosso caso o código do serviço estava sendo formatado, numa rotina antiga, com zero a esquerda ("0107") e deveria ser enviado apenas "107". Eu não tinha percebido o erro porque as filiais que estão funcionando o código do serviço é "1401".

Já fiz esta verificação do XML e não encontrei nada deste tipo. Os únicos dados que são diferentes são: IdentificacaoPrestador.ChaveDigital IdentificacaoPrestador.Cnpj IdentificacaoPrestador.InscricaoMunicipal ItemLei116AtividadeEconomica AliquotaISSQN DadosServico.Discriminacao DadosServico.CodigoCnae Os dados do tomador e os valores são os mesmos. Já esses campos acima são específicos, pois as empresas que estão funcionando são de assitência técnica de informática, e a outra é justamente a Software House.

Aqui estamos com esse erro também, porém apenas uma empresa do grupo. As outras 4 estão emitindo normalmente - todas com o sistema no mesmo servidor/banco de dados. Comparei o XML do RPS gerado e estão praticamente iguais, com apenas os dados do emitente/prestador do serviço diferentes. Também não obtive resposta da Agili até o momento.

Funciou a atualização. Obrigado.

Foi implementado para o provedor Agili uma quantidade mínima de RPS por lote, porém quando é utilizado a opção de emitir de forma unitária - Emitir('1', meUnitario, False) - acaba gerando um erro pois a quantidade máxima de RPS é 1 e a quantidade mínima é 2. Essa alteração foi enviada na revisão 30752 pelo @Italo Giurizzato Junior Vou analisar o fonte pra ver qual seria a melhor maneira de corrigir.

Esses testes são novos que apareceram no roteiro 3.01 de 04/04/2017, por isso que muita gente começou a cair nesse problema. Na página 2 do roteiro tem o histórico de alterações: Não sei quando foi liberado a versão do simulador Pay&Go que contemplava essa versão do roteiro, por isso pode ser que voce tenha feito a homologação antes desses testes se tornarem obrigatórios.

Marcou a nova propriedade do componente? Porque por padrão eu tinha deixado ele desmarcado.

Eu não utilizei esse valor reajustado, apenas tinha deixado pronto pra caso precisasse. Pelo que eu vi no exemplo do ACBr esse campo "ValorTotal" não esta sendo utilizado - está apenas mostrando num "memo" como log. Pode ser que precisamos guardar esse valor para um cancelamento posterior. Já no componente existe mesmo alguns tratamentos para saber o saldo restante mas não me aprofundei nisso. Talvez quem pode nos ajudar com essas dúvidas seja o @Roberto Kenji Yoshino, representante da NTK.

Eu tinha atualizado o repositório ontem para enviar esses dois arquivos. E até o momento não teve alteração neles. Tem alguma coisa errada então com a implementação? A alteração feita foi: * Criado propriedade "SuportaValorReajustado: Boolean" na unit ACBrTEFD.pas, da mesma forma que a "SuportaDesconto", para informar que será utilizada esta funcionalidade pelo TEF. * Criado propriedade "ValorReajustado: Double" na unit ACBrTEFDClass.pas, da mesma forma que a "Desconto", para retornar o valor retornado pelo TEF pelo campo 744-000. * Alterada a rotina "AdicionarIdentificacao" na unit ACBrTEFDClass.pas, para verificar a propriedade "SuportaValorReajustado" e somar o valor "64" ao campo 706-000.

Voce chegou a alterar o ACBr ou usou os fontes que eu postei acima? A versão atual do ACBr não tem implementado essa funcionalidade do teste 16.

No momento não consigo pegar o print, mas basicamente eu preenchi os dados de identificação e marquei a propriedade SuportaDesconto, SuportaSaque e SuportaValorReajustado - esta última propriedade eu criei.

O campo 706-000 é preenchido no arquivo de envio, indicando ao gerenciador quais funcionalidades são suportadas pela aplicação. O que vem no arquivo retorno é o 744-000, com o valor reajustado pelo TEF. Estou anexando os fontes alterados atualizados até hoje (06/06/2017). Fontes.zip

O campo 706-000 é preenchido no arquivo de envio, indicando ao gerenciador quais funcionalidades são suportadas pela aplicação. O que vem no arquivo retorno é o 744-000, com o valor reajustado pelo TEF.

Isso mesmo. Esse campo é a somatória dos valores de cada funcionalidade suportado pelo TEF. No caso seria: 1 (troco) + 2 (desconto) + 64 (reajuste) = 67.

Tem esse tópico com o mesmo problema. Lá eu comentei o problema e estou fazendo a implementação no fonte.

O problema foi que no roteiro versão 3.01 (04/04/2017) foram incluídos novos passos contemplando testes de Valor Reajustado e NSU Estendido. No caso do valor reajustado (passo 16 e 17) será necessário implementar um novo valor para o campo 706-000 (64: funcionalidade de valor reajustado) e tratar o campo 744-000 (Valor reajustado pela Rede Adquirente, conforme acordos contratuais com o estabelecimento, em centavos da moeda informada no campo 004-000). Vou fazer as alterações e posto aqui no forum.

Na emissão da NFe (XML) existem as informações de unidade de medida comercial e tributável (bem como valor unitário e quantidade) e esta informação deve ser impressa na DANFE para alguns produtos, como o GLP no estado do Mato Grosso. Alteração feita no post original: http://www.projetoacbr.com.br/forum/topic/27636-impressão-de-nfe-com-a-unidade-comercial-e-tributável-fastreport/#comment-220835

Bom dia, Como solicitado, estou enviando em anexo alterações que permitem a impressão na DANFE da NFe (Fast e Fortes) das duas unidades de medida (comercial e tributável), quando as mesmas são diferentes, assim como é feito no Emissor Gratuito da Sefaz SP. Os fontes estão atualizados com a versão de hoje (18/11/2016), utilizando o Fortes 4.0 e Fast 5.4.3. Foram alterados os arquivos: Fontes/PCNComum/pcnConversao.pas Criado o tipo "TImprimirUnidQtdeValor" com as opções: iuComercial (impressão apenas das informações comerciais) iuTributavel (impressão apenas das informações tributáveis) iuComercialETributavel (impressão apenas das informações comerciais e tributáveis) Exemplos/ACBrDFe/ACBrNFe/Delphi/Report/DANFePaisagem.fr3 Exemplos/ACBrDFe/ACBrNFe/Delphi/Report/DANFeRetrato.fr3 Exemplos/ACBrDFe/ACBrNFe/Delphi/Report/DANFeRetratoNovo.fr3 Alterado nos campos Unidade, Valor Unitario e Quantidade a propriedade WordWrap para True, para permitir que seu valor tenha mais de 1 linha (servirá para imprimir os dados da unidade comercial na primeira linha e da tributável na segunda linha). No arquivo DanfePaisagem.fr3 foi corrigido os campos Unidade, Qtde e Valor Unitário que estavam sempre retornando os valores da unidade tributável. Fontes/ACBrDFe/ACBrNFe/DANFE/ACBrNFeDANFEClass.pas Foram criados 3 funções formatar a Unidade de Medida, Quantidade e Valor Unitário quando utilizada a impressão da unidade comercial e tributada. Fontes/ACBrDFe/ACBrNFe/DANFE/NFe/Fast/ACBrNFeDANFEFR.pas O tipo da propriedade "ImprimirUnQtVlComercial" for alterada de "boolean" para "TImprimirUnidQtdeValor" (pcnConversao.pas) e inicializada por padrão como "iuTributavel". Fontes/ACBrDFe/ACBrNFe/DANFE/NFe/Fast/ACBrNFeDANFEFRDM.pas O tipo da propriedade "ImprimirUnQtVlComercial" for alterada de "boolean" para "TImprimirUnidQtdeValor" (pcnConversao.pas). A rotina "CarregaDadosProdutos" foi alterada para contemplar a alteração da propriedade "ImprimirUnQtVlComercial". Fontes/ACBrDFe/ACBrNFe/DANFE/NFe/Fortes/ACBrNFeDANFeRLClass.pas Criada a propriedade "ImprimirUnQtVlComercial: TImprimirUnidQtdeValor" (pcnConversao.pas) e inicializada por padrão como "iuTributavel". Fontes/ACBrDFe/ACBrNFe/DANFE/NFe/Fortes/ACBrNFeDANFeRLPaisagem.dfm Fontes/ACBrDFe/ACBrNFe/DANFE/NFe/Fortes/ACBrNFeDANFeRLPaisagem.pas Fontes/ACBrDFe/ACBrNFe/DANFE/NFe/Fortes/ACBrNFeDANFeRLRetrato.dfm Fontes/ACBrDFe/ACBrNFe/DANFE/NFe/Fortes/ACBrNFeDANFeRLRetrato.pas Alterados os componentes dos objetos txtUnidade, txtQuantidade e txtValorUnitario de "TRLLabel" para "TRLMemo". A rotina "rlbItensBeforePrint" foi alterada para contemplar a alteração da propriedade "ImprimirUnQtVlComercial". Anteriormente estava fixo a impressão apenas das informações comerciais. Arquivos de exemplo Fast-DANFePaisagem.pdf Fast-DANFeRetrato.pdf Fast-DANFeRetratoNovo.pdf Fortes-DANFePaisagem.pdf Fortes-DANFeRetrato.pdf acbr3.zip

As alterações já foram feitas e estão anexadas no tópico, mas ainda não foram analisadas e integradas no SVN.

Alguma novidade? Pois precisamos dessa alteração na DANFE.

Com essa alteração da erro de "Access Violation" quando executa "frxReport.PrepareReport" utilizando o arquivo "DANFSE.fr3".

Acabei de atualizar o repositório e o erro continua ocorrendo. Testei no Delphi 2010 e no Seattle. Aparentemente tem relação com a ordem de criação dos objetos em memória. Apenas quando é criado o objeto da NF-e primeiro e depois da NFS-e ocorre o erro. Em anexo esta o projeto atualizado com os testes de criação dos objetos. NFS-e.zip