Diogo Loff

Obrigado pelo retorno, no seu exemplo então é o percentual do beneficio e não o percentual da diferença, no fim me deixou com mais duvidas, pois nenhum cliente meu mandou exemplo assim. Os exemplos que me mandaram foram estes para o mesmo caso do 3% Suponhamos esta Venda Base ICMS: R$ 1.000,00 - % ICMS: 17 - Valor ICMS: R$ 170,00 Tem clientes que me mandaram exemplo assim: pCredPresumido = 82,35 vCredPresumido = 140,00 Quado é assim a base é usado o = valor do icms * pCredPresumido. Já outros clientes mandaram assim: pCredPresumido = 14 vCredPresumido = 140,00 Quado é assim a base é usado a = base do icms * pCredPresumido. E o seu exemplo: pCredPresumido = 3 vCredPresumido = 140,00 Quando é assim a base é o = valor do icms - (base do icms * pCredPresumido). Vou ter que pedir para algum cliente destes abrir consulta com a Sefaz, no fim fiquei com mais duvidas.

Fala @Juliomar Marchetti então já mandei aquele dia mensagem ao @marcopoloviana ainda não tive retorno, consegue dar uma força?

Valeu, Juliomar, acabei de mandar mensagem para ele. Obrigado.

Bom dia Panda, então voltei de férias agora tem duas semanas, não tinha visto ainda seu retorno. Em breve atualizo os fontes e lhe retorno. Obrigado.

Pessoal, estou com uma dificuldade de interpretação referênte aos campos de Crédito Presumido que vão entrar em vigor agora em SC, e já consultei contador nosso, também o contador dos clientes que vão ter esta adequação e ninguem soube me dizer. Olha complicado quando sobra pro Desenvolvedor descobrir hehe. Bom vamos lá. A duvida é referênte ao campo "pCredPresumido" qual é o percentual que vai aqui, é a Aliquiota do ICMS ou é o Fartor de de Redução, exemplo aqui das confeções que pagam 3% somente. Suponhamos esta Venda Base ICMS: R$ 1.000,00 - % ICMS: 17 - Valor ICMS: R$ 170,00 Tem clientes que me mandaram exemplo assim: pCredPresumido = 82,35 vCredPresumido = 140,00 Quado é assim a base é usado o valor do icms. Já outros clientes mandaram assim: pCredPresumido = 14 vCredPresumido = 140,00 Quado é assim a base é usado a base do icms. Em fim ambos os casos chegam no mesmo valor final, porem qual é o padrão certo, tem cliente falando que depende do TTD, mas não consigo entender como a NFe validaria isto, para mim é somente um padrão, pois se tivesse os dois padrões, no mínimo teria que ter um campo para indicar a Base do Crédito Presumido ou um Flag para indicar o tipo de calculo. Alguem sabe me informar com clareza o padrão adotado, pois vai influenciar na forma como vou parâmetrizar isto no sistema. Obrigado.

Bom dia, conseguiram dar uma avaliada?

Ola conseguiram dar uma avaliada neste item?

Valeu mestre!

Bom dia, segue aqui o que acontece com o fonte original. O XML mandei por e-mail, pois tem dados de cliente. Se estou emitindo a NFe não valido na receita e tento imprimir, ela fica correta: Porem após validar na receita ela fica errada, concatenando a ultima observação na sequencia: Aqui neste exemplo com o fonte original isto somente não acontece se informar uma observação no campo "InfAdic.infCpl". Se eu NÃO informar neste campo, e informar no primeiro "InfAdic.infAdFisco" e depois informar em outros InfAdic.obsFisco, InfAdic.procRef ou InfAdic.obsCont, qualquer um destes vai concatenar na "InfAdic.infAdFisco" após validar o XML. No exemplo estou informando infAdFisco e duas observações no obsCont. Com a customização que fiz este problema não acontece mais.

Opa boa tarde @Diego Foliene! Sim quando a questão do Pipe eu mesmo coloque fixo porque como disse o split não resolvia ai só resolveu pra mim, acredito que da forma como vc fez é o correto. Quando as observações que ficam ali erradas quando tem mais observações em sequencia, vou remover a alteração e te mandar o XML e o print da impressão para você ver o que acontece.

Então @Italo Giurizzato Junior boa tarde! A questão não é os FR3, e sim é a unit responsavel por montar eles. Já fiz meus testes e muitas coisas que ajustava ali já estão contempladas, tem duas situações que gostaria de pedir para ajustarem se possivel, uma eu acho que é falha pois é um campo que na impressão dos Danfse de algumas prefeituras/provedores tem, vocês tem a tag, mas não tem na classe de impressão. A outra é uma sugestão que deixa o bloco do "Descritivo" livre para usar com outras informações, como montar faturas, observações relacionadas aos itens, negociação comercial em fim. Já sugeri outras vezes, mas junto com outras solicitações que vocês não aceitaram, vou tentar novamente, mas olha com carinho. Item 1 (Implementação Faltante): ACBrNFSeXDANFSeFR.pas Provedor por exemplo Sigcorp da prefeitura de Chapecó/SC, na impressão do Danfe da prefeitura eles distingues DATA DA NFSE e DATA DO RPS, inclusive vocês leem a tag na leitura do XML, porem não tem o campo da DATA DO RPS na classe de impressão. Na linha 464 criado o campo no DataSert cdsIdentificacao.FieldDefs.Add('DataEmissaoRps', ftString, 19); Na linha 727 atribuido o campo ao report frxIdentificacao.FieldAliases.Add('DataEmissaoRps=DataEmissaoRps'); Na linha 1059 carregado o campo do objeto LCDS.FieldByName('DataEmissaoRps').AsString := ''; if ANFSe.DataEmissaoRps > 0 then LCDS.FieldByName('DataEmissaoRps').AsString := FormatDateBr(ANFSe.DataEmissaoRps); Observar que o campo já existe no objeto da NFSeX "ANFSe.DataEmissaoRps" ele somente não tem uma tag para impressão, lembrando que a adição desta tag não causa problemas se o report não tiver a mesmoa explicita dentro dele. Item 2 (Sugestão): ACBrNFSeXDANFSeClass.pas Criado propriedade para o componente TACBrNFSeXDANFSeClass chamada "ForcaDetalhamento". Esta propriedade é default Falso para assim não contaminar quem já utiliza. O intuido dela é se for setada como Verdadeira, ela sobrescreve no arquivo ACBrNFSeXDANFSeFR.pas na linha 1549 para forçar que o objeto "Memo13" seja sempre impresso. Este memo13 já existe é o do detalhamento, porem se na impressão os itens são passados de forma tabulada, este memo desaparece, para que é usado este memo, para adição de outras informações, como faturas, obsevações comerciais, etc. frxReport.FindObject('Memo13').Visible := (not ((cdsItensServico.RecordCount > 0) and (frxReport.FindObject('Page2') <> nil)) or (frxReport.FindObject('Page2') = nil)) or (DANFSeXClassOwner.ForcaDetalhamento); Sobre esta parte do detalhamento olha como fica legal se poder forçar na impressão, estou usando o FR3 padrão de vocês. Sem esta opção que citei, se eu quiser usar os itens tabulados a parte ali onde por exemplo esta saindo a forma de pagamento fica invisivel (que é o memo13), inclusive o Danfe estsa quebrando certinho se possuir mais itens e tal. Os clientes acham melhor visual assim e mais completo. Para que tem curiosidade as parcelas ali eu monto em texto corrido com tabs e usando | por exemplo para ficar formatado, isto o proprio ACBr já trata. Agradeço muito se puderem levar em conta estas melhorias. Segue anexo os fontes. Fontes.zip

Bom acabei ficando doente e não pude responder, hoje nã oestou trabalhando tb. Mas vou fazer o seguinte vou testar todas as opções e tentar ver se consigo eliminar total as customizações. Se ficar alguma coisa mando sugestão se for pertinente, até final da semana que vem respondo.

Boa tarde, galera! Seguinte, esta semana tive que atualizar todos os fontes do ACBr, e com relação ao NFSeX tenho várias customizações no DANFE, queria eliminar isto de forma completa, gostaria de usar os modelos disponibilizados pelo componente como acontece hoje com a NFe que é perfeito. Então a pergunta que tenho a fazer é: Quais dos modelos vocês indicam eu utilizar com base nos que tem disponivel no repositório? Até hoje atendo a várias cidades de diferente provedores, e sempre utilizo o modelo sem qr code com código de autorização pequeno, e outro quando a prefeitura tem o código de autorização grande com qr code. Para meus clientes o que é importante é que a descrição dos serviços, observações e dados de pagamento (faturas) saiam completos. Obrigado A um detalhe eu uso FastReports.

Bom dia, na carta de correção quando a mesma é feita para Ator Interessado não esta apresentando as informações de forma completa. Isto já acontecia antes, porem nunca mandei o ajuste pois estava usando uma versão antiga, agora que atualizei ainda permanece a mesma situação. Anexo dois reports em PDF o sem alteração e o com a alteração. Anexo também o fonte alterado ACBrNFeDANFEFRDM.pas. Neste fonte tem outras alterações que estão sendo tratadas em outro chamado relacionado a quebra de observações da NFe, então se ater somente ao bloco do Evento. procedure TACBrNFeFRClass.CarregaDadosEventos; 1 - Na metade desa rotina tem uma linha assim: if (InfEvento.tpEvento <> teCCe) then begin FieldByName('xJust').AsString := InfEvento.detEvento.xJust; if InfEvento.tpEvento = teInsucessoEntregaNFe then FieldByName('xJust').AsString := InfEvento.detEvento.xJustMotivo; end else begin ....... end Neste precisa colocar na condição do IF para que o mesmo caia no Else quando for Ator Interessado, aqui resolve para aparecer a condição de uso na impressão. if (InfEvento.tpEvento <> teCCe) and (InfEvento.tpEvento <> teAtorInteressadoNFe) then 2 - Ao final do mesmo bloco adicionar para carregar o ator interessado, usado o mesmo campo xJust pois este campo na impressão já vem para este fim, conforme o label quando é impresso. Aqui fixei um, pelo que vi não ha previsão de mais de um, mas talvez já teria que pensar em mais de um interessado. if (InfEvento.tpEvento = teAtorInteressadoNFe) then begin documentoAtor := InfEvento.detEvento.autXML[0].CNPJCPF; FieldByName('xJust').AsString := 'CNPJ: ' + documentoAtor; if (documentoAtor > '') and (length(documentoAtor) < 14) then FieldByName('xJust').AsString := 'CPF: ' + documentoAtor; if (InfEvento.detEvento.tpAutorizacao <> taNaoInformar) then FieldByName('xJust').AsString := FieldByName('xJust').AsString + ' - Tipo Autorização: ' + AutorizacaoToStr(InfEvento.detEvento.tpAutorizacao); end; ObrigadoACBrNFeDANFEFRDM.zip EVENTOS SEM AJUSTE.pdf EVENTOS COM AJUSTE.pdf

Neste item coloquei uma sugestão da parte dos eventos para converter o encoding. Não precisa mais, de alguma forma na versão nova esta vindo correto, provavelmente foi ajustado em outro ponto.