Agnaldo Prates

Eu calculo os novos valores. Afinal, o novo vencimento não estava previsto e por uma excepcionalidade você deverá atualizar o boleto com os novos valores e vencimento.

Com certeza! Eu faço isso. Gero novamente o boleto com novos valores e vencimento. Depois gerar o arquivo de remessa. Lembre-se de que, TipoOcorrencia = toRemessaAlterarVencimento Veja no Demo. OcorrenciaOriginal.Tipo := toRemessaAlterarVencimento;

Bom dia Maicon. Li o seu texto e confesso que me senti parte dessa história. O árduo caminho que o desenvolvedor percorre no decorrer da sua caminhada, muitas vezes nem é percebido por terceiros, quiçá para instituições bancárias que estão protegidas pelo manto sagrado da burocracia, tendo como pilar fundamental a famigerada FEBRABAN. Não cabe aqui fazer um juízo de valor sobre os procedimentos utilizados por estas instituições, não, afinal, lá existem colegas desenvolvedores que são obrigados a seguir o script do empregador. Por outro lado, o desserviço prestado pela FEBRABAN conjuntamente com outros órgãos correlatos, é o que causa toda essa celeuma de manuais de orientação que nada mais é do que uma maneira de o “BANCO” vender mais um serviço para o correntista, ou seja, forçar o cliente a aderir aos seus aplicativos, afinal, os bancos vivem de serviços né? Note-se que, se fosse séria a questão da cobrança bancária, já haveria um webservice do BC gerenciando toda massa de dados relativos à cobrança em si, mas como sabemos, Banco Central não está nem aí para estas questões. Destarte, eu aconselho você, ou quem dispor de algum tipo de problema similar, que, não fique no e-mail, faça um documento escrito, vá na agência e protocole, sabe por qual motivo? Na hora que você perder o cliente, e isso deve estar expresso que foi em virtude do não atendimento pela instituição, poderá judicialmente requerer uma indenização por perda de chance ou mesmo lucros cessantes. Garanto que, no momento que for solicitado a protocolização, alguém tomará as devidas providências para que não incorram em uma futura obrigação de indenizar.

Caro Giovanne. Pelo exposto, o PROCOM notificou teu cliente para que seja inserido no cabeçalho do DANFE NFC-e o número da inscrição Estadual. Você poderia descrever qual a fundamentação legal da notificação? Foi com base em alguma lei? Se sim, eles informaram? Caso não, você tem duas alternativas: i) No caso do DANFE NFC-e atual, não há previsão para que a IE do emitente seja impressa, segundo o que dispõe o Manual de Orientações técnicas, p.7 item 3.1, divisão I, não faz nenhuma referência à exigência do referido órgão. ii) Caso queira inserir a IE no respectivo DANFE-NFC-e, poderá fazê-lo sem nenhum prejuízo ou possibilidade de sanção, uma vez que, no arquivo .xml, que é o documento com validade jurídica, há a tag <emit><IE>. Ou seja, se o PROCON está solicitando esta informação é possível que seja inserida. Por outro lado, a função primordial do PROCON não é essa, fiscalizar “ausência” de inscrição estadual em DANFE NFC-e. Sua principal função é a de auxiliar o consumidor nas relações de consumo, como fiscalizar abusos praticados por fornecedores de produtos e serviços tanto pela via administrativa quanto pela via judicial. Não parece que a ausência do número de inscrição estadual no DANFE NFC-e, cause alguma lesão ao direito do consumidor, pelo contrário, trata-se apenas de uma representação em papel dos dados básicos do fornecedor. Assim sendo, cabe a você tomar uma decisão do que fazer. Comunicar o órgão do PROCON sobre a orientação extraída dos respectivos manuais técnicos disponibilizados pelo ENCAT.

A depender de qual situação, não há solução. O que há na verdade, seguindo o texto original do tópico, trata-se de DIFAL. Ou seja, parece que estão tentando colocar alíquota interestadual do MS para 7% o que não é. Para os estados do sul: PR, RS e SC, 7% Estados do sudeste MG , RJ e SP 7% ( Apesar do ES está no sudeste não se aplica a alíquota interestadual de 7% e sim de 12% ). Para todos os demais estados, a alíquota interestadual é 12% Qual a verdadeira função destas alíquotas diferenciadas? Trata-se de um mecanismo encontrado pela União no sentido de ajudar aos estados não tão desenvolvidos como PR, RS, SC, SP, RJ e MG. Ou seja, é permitir que se arrecade um pouco mais nestes estados "pobres".

Bom dia. Não é muito complexo, veja: 020 é para transportador cadastrado com contribuinte do ICMS. 090 no caso de transportador autônomo O problema é a questão da substituição tributária 060. Veja: Qualquer que for o regime de recolhimento do transportador, o remetente deduzirá 20% do imposto a ser recolhido. Caso o transportador utilize o regime débito e crédito se for o caso, deverá estornar os créditos oriundos desta prestação no referido período. Portanto, o problema maior trata-se justamente da substituição tributária.

No OnCreate do seu form principal, faça: DecimalSeparator := '.'; Lembre-se, que será um ponto no lugar da vírgula. Para o valor de R$ 1.280,53 ficará: R$ 1.280.53

José. Segue em anexo as units modificadas. AcbrBoleto.pas ACBrBancoBancoob.pas. Vale lembrar que estas alterações que fiz, estão atendendo a SicoobCentro, conforme frisei no post anterior. ACBrBancoBancoob.pas ACBrBoleto.pas

De tanto apanhar com esse monte de " Layout_Para_Troca_de_Informacoes.xls", cada centro tem um, eu tive que criar as seguintes propriedades no AcbrBoleto. Protected fLayoutVersao_HF : String; // Versão do Hearder do arquivo fLayoutVersao_HL : String; // Versão do Hearder do Lote public (...) Property LayoutVersao_HF:String read fLayoutVersao_HF write fLayoutVersao_HF; Property LayoutVersao_HL:String read fLayoutVersao_HL write fLayoutVersao_HL; (...) TACBrBancoClass.create(AOwner: TACBrBanco) fLayoutVersao_HF := '87'; // Este é o atual da Sicoob Centro fLayoutVersao_HL := '40'; // Este é o atual da Sicoob Centro Ou seja, se houvesse uma padronização, não haveria problema nenhum. Com diante disso, na hora de gerar os arquivos, eu alimento esta propriedade. AcbrBancoBancoob.pas GerarRegistroHeader240... (...) PadLeft(OnlyNumber(LayoutVersao_HF),3,'0') + // 164 a 166 - Número da versão do layout do arquivo ( Antes estava fixo, criei o campo) PadLeft(OnlyNumber(LayoutVersao_HL),3,'0') + // 164 a 166 - Número da versão do layout do arquivo ( Antes estava fixo, criei o campo ) Eu tive que fazer isso. Na hora de atualizar o ACBrBoleto é que são elas. Tenho que fazer um Backup destas units e alterá-las conforme as mudanças nas novas.

Depende: indEscala = Indicador de Produção em escala relevante, conforme cláusula 23 do Convenio ICMS 52/2017 e comporta os seguintes valores: S - Produzido em escala relevante; N – Produzido em escala não relevante. CNPJ do Fabricante da Mercadoria - Obrigatório para produto em escala não relevante. cBenef = Código de Benefício Fiscal utilizado pela UF aplicado ao tem. Obs.: Deve ser utilizado o mesmo código adotado na EFD e outras declarações, nas UF que o exigem. Note que, se informado N, deverá obrigatoriamente informar o CNPJ do fabricante. Fonte NT_2016_002_v1.2. p.13.

-Configuracoes.Geral.SSlib := libWinCrypt -Configuracoes.Geral.SSLCryptLib := cryWinCrypt; -Configuracoes.Geral.SSLHttpLib := httpWinHttp; -Configuracoes.Geral.SSLXmlSignLib := xsMsXml; Não se se está assim ai, mas o componente se configurado como acima citado, deverá conter, no caso do A1: - Número de série - Path do arquivo .pfx - Senha. No caso do A3, eu apenas informo o número de série. Isso aqui resolveu.

Bom dia. A questão do lançamento do crédito presumido nos serviços de transporte, não é complexa. Trata-se de uma operação simples, mas, diante do que dispõe as normas tributárias, causa uma certa dúvida quanto à aplicação prática. Vejamos: No caso do referido crédito de 20%, fora os requisitos burocráticos que a transportadora deve segui para seu enquadramento, a coisa é bem simples. Vamos supor que em um transporte, a transportadora cobrou R$ 5.000,00 para a prestação do serviço. Imaginemos que seja uma alíquota modal de 18,00% em uma determinada unidade da federação, então passamos ao cálculo. R$ 5.000,00 x 18,00% = R$ 900,00 que é o ICMS supostamente devido pela transportadora ao Estado, esta é a parte geral. De posse desta informação, é hora de alimentar as tags do xml do CT-e. No caso de redução CST 020 e do referido crédito, CST 060 e CST 090. Destaque-se que, para saber qual tag alimentar, é importante que se analise a situação tributária em si. No exemplo de R$ 5.000,00 x 18,00% = R$ 900,00, o valor do crédito recai sobre 900, então o crédito será de R$ 180,00, e o valor efetivamente devido será de R$ 720,00. Diante disso é só informar os respectivos valores nas referidas tags do XML que devem estar previstas no guia de integração. Creio que seja isso.

Qual certificado está usando?

ACBrNFse1.Configuracoes.Arquivos.PathSchemas := "Informe onde está o arquivo de Schemas".

O sistema está reclamando a falta do arquivo nfse.xsd do provedor, se existir, e na pasta ele não está. Há duas alternativas possíveis: i) Colocar o arquivo nfse.xsd nesta pasta; ii) Informar ao aplicativo que o .xsd a ser utilizado é nfse_3.xsd e não nfse.xsd Na pasta schemas do meu sistema está o nome do provedor e dentro dela está: nfse.xsd e xmldsig-core-schema20020212.xsd.

Razão assiste ao @André Ferreira de Moraes. Segundo o que dispõe o manual de especificações técnicas, o referido acréscimo não poderá ser implementado, visto que há vedação expressa. "No DANFE NFC-e não devem ser inseridas informações que não constem do respectivo arquivo eletrônico XML da NFC-e" p.2 do referido manual. Para contornar tal situação, eu passei a usar o campo VOutro para informar o acréscimo bem como outras despesas caso haja. Não sei se um dia a nfe/nfc-e terá esta tag específica, uma vez que muitos contribuintes a utilizam, em fim, como não há a tag vAcrescimo no xml, vou usando o vOutro mesmo.

Bom dia. Veja que situação interessante. Isso ocorre todos os dias com muitos clientes meus. Infelizmente a prática comercial e as normas tributárias ainda encontrarão muitos casos parecidos com este e o mais grave, talvez mais difícil de resolver. Na NFe a autorização refere-se ao cumprimento da obrigação por parte do cliente e neste caso, quem sabe desta informação é o estado. O Município por sua vez, fica sem saber como foi pago, mas para ele isso "pouco importa", o que também se aplicaria ao estado. O cerne da questão para o fisco é saber a posteriori a movimentação via operadoras de cartão de crédito / débito, para de posse desta informação fazer incidir o ISS sobre tal prestação de serviço, mas isso já e tema que aguarda definição do Congresso Nacional, se é uma prestação de serviço que incida o ICMS ou o ISS, a tendência é que incidirá o ICMS, assim como serviços de telefonia, tv a cabo etc. No seu caso, não importa em tese se a autorização é um valor e a NFe é outro. Pode ficar tranquilo que a briga será entre gigantes, Estado, Municípios e Operadoras de cartões. Quanto à consistência das informações, na minha venda informo o total dos produtos e dos serviços bem como a identificação da NFe e NFs-e, no relatório, Produtos: R$ 1.120,00, Serviços: R$ 80,00, Valor pago: R$ 1.200,00, Tipo de Pagamento: Cartão de crédito. É isso.

"[...]desde que recebido até 480", ultrapassado este prazo há que se cogitar a incidência da multa prevista. Portanto, fora do prazo a que se refere o texto regulamentar de 480 horas da autorização, e não do prazo de 24 horas.

Bom dia. Vamos por parte. Quanto ao cancelamento fora do prazo. Trata-se de uma discricionariedade da unidade federada, ela quem escolhe se aceita tal evento ou não. Portanto, caso aceite, é válido o cancelamento sem nenhuma sanção aplicável. Quanto a validar ou não. Neste ponto, se o retorno veio com aceitação, ou seja, o fisco homologou “permitiu” que fosse cancelada a nota, não há o que discutir, deverá ser validado no software e/ou banco de dados. Quanto a futura multa. No caso em questão, conforme acima citado, em sendo homologado o cancelamento mesmo fora do prazo e se assim foi aceito, não há o que se falar em penalidades. Quanto a culpa do desenvolvedor. Neste caso, há que se destacar o dolo ou conluio. Caso seja elaborada algum artifício capaz de burlar a legislação aí sim, são responsáveis solidários, o empresário e os responsáveis pelo software. Importante ressaltar que, embora a cultura do “jeitinho brasileiro” ainda tem lugar no meio de alguns empresários, é importante destacar a vontade deste ou mesmo a sua omissão quanto às obrigações fiscais. Não é aceitável que terceiro de boa-fé seja penalizado pelo uso inadequado ou inapropriado de uma ferramenta posta no mercado para fins legais em detrimento às normas de regência. Assim sendo, esta “cultura” de que a culpa é do software/desenvolvedor já caiu por terra faz um bom tempo, mas, toda precação é importante e deverá ser aplicada, especialmente no que diz respeito a operações onde há os olhos do estado voltados para o interesse público. Espero que tenha respondido senão todas, mas pelo menos boa parte das suas dúvidas.

@BigWings, não sei se há esta regra. Outro ponto, o pICMSInterPart, também só informo caso haja ICMS e a operação não seja interna.

Rejeição. No caso, não se trata de Schemas desatualizados, tendo em vista que estou utilizado os que estão no ACBr atualizado ontem. Quanto à TAG ICMSUFDest , somente é alimentada se houver efetivamente ICMS, o que não era o caso pois a CST era 060. Motivo pelo qual fiz as alterações antes citadas, o que resolveu e a nota foi enviada normalmente.

Olá pessoal, bom dia. Tentei enviar uma NFe com os novos Schemas, porém, estava retornando a rejeição em que o vFCPUFDest não era esperado. Tratava-se de uma nota de simples remessa interna e sem a incidência do ICMS. A referida tag é gerada pelo pcnNFew. Alterei a unit pcnNFew para gerar a tag em questão caso haja valor do ICMS, assim sendo, se for pertinente tal modificação, posto-o aqui para análise dos moderadores. Abraço.

Eu utilizo assim: nTotalProduto := RoundABNT( nQuantidade * nPrecoProduto),2); nImposto := RoundABNT( (nTotalProduto * nPercentual)/100),2); Sempre dá certo. Sempre dá certo.

Você está com problemas de arredondamento. vFCPUFDest=15,48 vFCPUFDest=15,49 faça na calculadora, 774,50 * 2 / 100 Use a função RoundABNT() do ACBr que dá certo.

Juliomar, salvo engano, tratava-se da frxe14.dcp do fastreport, como apaguei o log não posso precisar exatamente qual foi, mas era em relação ao danfe do fast, que, me parece não tem relação com o instalador em si.