Agnaldo Prates

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.

Eu passei por isso também. Removi a pasta do ACBr "fiz um backup" e baixei novamente, instalou normal. Entretanto eu tenho algumas modificações específicas na unit ACBrBancoBancoob, devido à algumas particularidades no retorno do CNAB400, tendo em vista que necessito do CNPJ do cliente. Outro ponto importante é que, no Delphi 10.2 o instalador funciona 100%, já no D2010, eu tive que instalar manualmente, visto que ocorre alguns erros. Outro detalhe que observei, é que o instalador adiciona na libray path, caminho de alguns componentes que não são setados para instalação, por isso resolvi mesmo instalar manualmente.

Possivelmente há algo sem atualizar. No meu caso, atualizei pelo update, porém, na hora de compilar os pacotes estava com esse pequeno problema. Removei toda a pasta e atualizei novamente, funcionou beleza. Talvez seja isso. Outro ponto fundamental é usar o ApagarACbr.bat, eu utilizei antes de atualizar.

Use as propriedades do componente. TamanhoLogoHeight := Altura TamanhoLogoWidth := Largura LogoemCima := True FormularioContinuo:=True ExpandirLogoMarca:=False Isso deve resolver.

Produto Quantidade Vendida Preço Unitário Total Valor Desconto Total Liquido Pacote de Café 10 3,50 35,00 5,00 30,00 -------------------------------------------------------------------------------------------------------------------------------------- Sobre os seguintes campos da tag <prod> da nfe, o que devo utilizar: qCom: 10 (quantidade vendida) vDesc: 5,00 uCom:= PCT ( ou a unidade definida no teu sistema ) uTrib:= PCT (ou a unidade definida no teu sistema ) Então vProd = ( qCom * vUnCom)

Realmente o seu questionamento não é sobre a aplicação da norma jurídica, claro que não. O que acredito é que talvez, ao ler, não observou que, para que possa protestar, é necessário que haja uma configuração, como, dias para protesto entre outras instruções que devem ser preenchidas no componente. Quando eu citei "[...] Se houver essa previsão na carteira do cliente juntamente com a instituição bancária, tudo bem, ai é uma questão contratual [...]", foi justamente para que você observasse se, a sua carteira no caso, a 109, há essa previsão. Isso porque, conforme estabelece o manual do banco, "Existindo a figura do Sacador/Avalista, é imprescindível informar corretamente todos os dados a ele relacionados, conforme lei federal 12.039, que exige os dados completos para facilitar o contato entre sacado e o emissor e, caso venha a ser solicitado o protesto da dívida, é facultado aos Cartórios de Protestos de Títulos exigirem tais dados com exatidão". p. 30, disponível em: http://download.itau.com.br/bankline/layout_cobranca_400bytes_cnab_itau_mensagem.pdf. Portanto, havendo inconsistências nas informações, creio que os dados não serão gerados, embora tenham sido informados. Creio que há dados que são obrigatórios e que não estão atendendo aos requisitos.