marcianobandeira

Bom dia, conversei com um contador experiente aqui, chegamos na conclusão que o melhor a ser feito é criar um campo para informar a aliquota de icms desonerado, de modo a poder informar o valor que seria a tributação do produto caso não houvesse a desoneração/isenção. Vou partir por essa linha.

Bom dia.. creio que esse OU não seja "tão OU assim", rs... Fiz um teste aqui informando conforme sugerido acima para forçar a geração da tag, na sefaz PR ambiente de homologação // dad.Imposto.ICMS.motDesICMS := mdiOutros; // dad.Imposto.ICMS.vICMSDeson := 0.0001; o xml gerou da seguinte forma <ICMS> <ICMS40> <orig>0</orig> <CST>40</CST> <vICMSDeson>0.00</vICMSDeson> <motDesICMS>9</motDesICMS> </ICMS40> </ICMS> aí recebi a mensagem conforme a imagem abaixo "O valor do ICMS desonerado deve ser informado"..

Boa tarde, Eu realmente fui procurar a nota técnica aqui e já enviei o embasamento legal para o cliente. Muito obrigado. É uma alternativa, vou propor isso ao cliente. Obrigado

Boa José, O caso em questão é de um cliente que usava um sistema anterior, e o bendito sistema anterior fez uma "gambiarra" pra sair essas informações no DACTe, mas consultando na sefaz realmente não existem tais informações. Muito obrigado pelos esclarecimentos

Boa tarde Ao atender um chamado de um cliente, notei que o CT-e (Fortes Retrato) não está imprimindo os dados do veículo nem do motorista. Ao analisar o método rlb_10_ModRodFracionadoBeforePrint notei o seguinte trecho de código: rlb_11_ModRodLot104.Enabled := False; A única possibilidade dessa propriedade receber True é se a versão do XML do CT-e for inferior a 3.0. Se eu simplesmente atribuir True nessa propriedade eu tenho o funcionamento esperado. Porém analisando o código, notei uma variável global dentro da unit ACBrCTeDACTeRLRetrato "Versao: integer;" também há uma verificação sobre qual banda habilitar conforme esta variavel if Versao = 103 then rlb_11_ModRodLot103.Enabled := True else rlb_11_ModRodLot104.Enabled := True; De qualquer forma esse trecho de código só é acionado se a versão do XML for inferior a 3.0. Não consegui entender o objetivo da variavel Versao, uma vez que essa variável é preenchida diretamente com o valor 200 no método RLCTeBeforePrint. Se alguem puder dar uma luz. Grato

Pois eh, tive o mesmo problema com o tef auttar que não aceitava parametrização alguma, então sempre indico CliSitef ou Pay&Go aos meus clientes, nessa ordem.

Esse OperacaoCRT creio que so vai funcionar para o CliSitef. Esse GlobalTef Plus eu nao conheço. No caso do pay&go vai ter que usar como voce postou acima mesmo.. Req.GravaInformacao(10,0,'Cielo'); // Operadora Req.GravaInformacao(11,0,'10'); // No meu caso nao informo isso Req.GravaInformacao(18,0,'02'); // qtd parcelas apenas para teste Req.GravaInformacao(730,0,'1'); // VENDA Req.GravaInformacao(731,0,'1'); // CREDITO se fosse DEBITO vc informaria 2 Req.GravaInformacao(732,0,'1'); // AQUI PARECE ESTAR SEU PROBLEMA, POIS ESTA INFORMANDO SE TRATAR DE UMA VENDA A VISTA - NO CASO DE PARCELADO LOJA INFORMAR 3 Req.GravaInformacao(739,0,'001'); // isso aqui também nao informo aqui no meu caso.

Voce ta usando o CliSitef ou o Pay&Go?

Veja esta postagem: Postado por giulianon em 29/12/2017 https://www.projetoacbr.com.br/forum/topic/39273-clisitef-autoatendimento/ Para iniciar direto no débito ACBrTEFD.TEFCliSiTef.OperacaoCRT := 2; Para iniciar direto no crédito ACBrTEFD.TEFCliSiTef.OperacaoCRT := 3; Na documentação do clisitef tem todos os códigos de todas as operações que você pode utilizar. Qualquer dúvida estamos a disposição.

Boa tarde, Basta informar a propriedade OperacaoCRT. ACBrTEFD.TEFCliSiTef.OperacaoCRT := Se não me falha a memória, 2 pra débito e 3 pra crédito.

Bom dia Alguém passado por problemas com a emissão de NFS-e com o provedor PronimV2? Desde semana passada estou recebendo a mensagem: "Empresa - A entidade não satisfaz a especificação: OptanteSimplesNacional: Deve ser informado se a empresa e optante do Simples Nacional" Meu xml gerado tem a tag <OptanteSimplesNacional>1</OptanteSimplesNacional> Tentei entrar em contato com a prefeitura, mas só me dizem que o xml está fora do padrão. Se alguém puder dar uma luz. Grato

Boa tarde Senhores, Segue em anexo a minha proposta de mudança. Basicamente eu removi a propriedade CodigoMora deixando apenas a propriedade CodigoMoraJuros. Adicionei também a propriedade CodigoJurosMoraAceitos para que cada classe de banco possa informar quais sao os aceitos, caso sejam diferentes de (Valor por dia, Taxa mensal e Isento). Criei os metodos CodigoMoraJurosToStr e StrToCodigoMoraJuros na classe TACBrBancoClass.. esse método pode ser sobrescrito por outras classes, mas a exemplo da classe TACBrBanrisul podem ver que não é necessário sobrescrever o método. Algo que pode ser chato e provavelmente alguns desenvolvedores tenham que ajustar seus codigos é quanto a validação adicionada ao gerar o arquivo de remessa. Apesar de poder causar alguns transtornos, não causará a falsa sensação de estar tudo bem, podendo neste caso sim, gerar transtornos maiores no futuro. Realizei os testes aqui basicamente com o sicredi. Att, ACBrBoleto.rar

Boa tarde @Juliana Tamizou e @José M. S. Junior Temos duas propriedades na classe ACBrTitulo, CodigoMora e CodigoMoraJuros. Notei que algumas classes provavelmente mais recentes, usam esta propriedade CodigoMoraJuros. Estou criando as validações aqui para a propriedade CodigoMora, mas creio que talvez fosse melhor eliminar essa propriedade, deixando apenas a propriedade CodigoMoraJuros. Assim cada classe de banco nova que fosse diferente do padrão, poderia simplesmente sobrescrever um método para deixar com o código correto, a exemplo da função CodJurosToStr que tem na unit TACBrBancoUnicredES. Creio que neste caso também poderia ser eliminado a propriedade CodigosMoraAceitos, ou ao menso ser trocada para um Set of TACBrCodigoJuros ao invés de string. O que acham?

Bom dia, vou implementar uma sugestão e anexo os fontes aqui mais tarde.

Boa tarde Juliana, Obrigado por responder, mas na minha humilde opinião, dessa forma o desenvolvedor tem a falsa sensação de que está tudo ok, como foi o que aconteceu comigo, eu so vi o problema estourar quando ja era bem tarde, ja havia varios boletos emitidos. Creio que talvez fosse melhor separar a propriedade CodigosMoraAceitos em (CodigosMoraAceitosCnab400 e CodigosMoraAceitosCnab240). Também seria interessante tirar a validação do metodo TACBrTitulo.SetCodigoMora e colocar na geração do arquivo de remessa, pois como teríamos uma validação para cada tipo de layout, esse método poderia ser falho. Caso ache que fica interessante, eu me proponho a desenvolver sim. Att,