Agnaldo Prates

Exatamente isso, depois de 720hs somente através do Processo Administrativo Fiscal. Ou seja, isso não tem nenhuma relação com sua aplicação / sistema. Eu conheço contadores que as vezes fica jogando o cliente contra o sistema sem sequer procurar mais informações. Eu tive um problema em que o cliente tinha vários PDVs, ao implantar a NFCe, tive que criar uma série para cada um deles. O contador ficou furioso, dizendo que não poderia criar várias séries para a NFCe. Eu apenas lhe enviei um email com as respostas obtidas de uma consulta feira à SEFAZ/AM sobre o tema, sendo que lá era o ambiente de homologação. Assim sendo, infelizmente ainda existem contadores que são apenas "contadores" e não não o novo profissional da contabilidade atual.

Sua declaração "LEFT" não está correta. Utilize "INNER" Procure mais informações sobre LEFT, INNER, RIGHT, FULL etc.

Bom dia Marcos. Veja que em poucas palavras você colocou tanta tese que dá para elaborar um bom artigo. Não é possível emitir uma carta de correção para nota enviada a mais de 30 dias. Se o contador afirma ser possível, é melhor ele rever os próprios conceitos. Na NT2011_004, item 6.2 é cristalina esta restrição. No caso de CND, seu cliente poderá solicitar junto a secretaria de finanças do estado, através do PAF, a análise da referida situação, haja visto que há impedimento legal para emissão da referida CCe. Assim sento, resume-se que, tanto o teu cliente quanto o contador estão tentando arrumar uma solução fácil para problema difícil.

Se estiver como true a opção RetirarAcentos do componente vai ser retirado sim.

Falta alimentar a tag: vFCP no Total. p. 29 da NT_2016_002_v1.00

Bom. Não se trata de erro propriamente dito. O que há é uma regra de validação de rastreabilidade do produto, que, no caso não se sabe qual, porém pelo que dispõe o manual, trata-se de produto sujeito a regulações sanitárias. Você preencheu as tags relativas ao grupo I80? p. 10 NT_2016_002_v1.00, disponível em: https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=c4S6yXTKpXY=.

Ainda é a questão da linha digitável no recibo do pagador? Se for. Faça uma cópia de segurança na unit ACBrBoletoFCFortesFr.pas, altere o layout de acordo com o desejo deles e faça sua homologação.

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.