Diogo Loff

Fiz a atualização esta mês do ACBr, já passou a versão nos testes. Nós usamos várias funções dentre as principais a NFe e NFS-e, bom pois bem não tive que realizar customizações mais, todas foram atendidas com exceção desta sugestão que esta neste tópico. Então ficaria grato se existisse a possibilidade apresentada, pois não exigiria mais customização alguma aqui. Lembrando que a questão da DataEmissaoRps na minha visão é falha na implementação, pois na lógica vocês reutilizam outro campo que é a Data da NFSe, e a prefeitura de Chapecó por exemplo no Danfse tem a distinção das duas datas. E o outro item seria somente um parâmetro novo na configuração para deixar a questão do corpo mais flexivel.

Para quem ainda tem duvidas quanto ao controle dos percentuais do crédito presumido. A Sefaz vai prorrogar a obrigatoriedade de preencher o percentual e o valor, assim como no video mostrado, somente será obrigatorio mesmo a informação do código do beneficio, por enquanto. Pelo que vi em minhas pesquisas eles vão padronizar o calculo para que não existam duvidas. Também tem outras questões envolvidas como por exemplo empresas que vão utilizando o credito presumido e derrepente ele acaba, pois tem um sistema de cota para usar dentro do ano corrente, então tem uma série de coisas que a Sefaz entendeu que ficou complexo.

Fala @Victor H. Gonzales - Panda fiquei de dar um retorno, mas somente este mês que atualizei o ACBr por completo novamente. Este item ficou perfeito valeu a atenção.

Muito bom o video com as explicações, é realmente faz sentido removerem a obrigatoriedade destes campos do percentual e valor, pois realmente conversando com muita gente aqui em SC ninguem sabe ao certo o que preencher.

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