Agnaldo Prates

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.

Boa noite. Primeiro, todas as notas foram rejeitadas pois o CSC era para outro CNPJ. Neste caso, deverá inutilizar tais numerações para o referido CNPJ. Depois todas as notas deverão ser geradas novamente com o CSC para o respectivo CNPJ. Segundo: Enviar para o escritório de contabilidade, ofício relatando exatamente o motivo pelo qual, no respectivo CNPJ não houve movimentação, relatando ainda os números inutilizados.. Terceiro. Enviar um comunicado oficial para a fazenda pública estadual, relatando o ocorrido. Quem faz isso? O setor de contabilidade ou o escritório. Com isso, a receita estadual vai entender o que houve e, com base netas informações elidir quaisquer hipóteses de fiscalização e/ou um lançamento de um crédito tributário presumido.

Bom dia. Protestar o fiador junto com o cliente. Cara, se fosse no meu caso, eu jamais faria isso, porem, cada cliente pensa de um jeito. Se houver essa previsão na carteira do cliente juntamente com a instituição bancária, tudo bem, ai é uma questão contratual, entre banco e cliente. O fiador é corresponsável pelo pagamento da dívida, assim sendo, poderá ser sim protestado juntamente com o cliente. Porem, não são todos os clientes que possuem um fiador, muitos possuem avalistas o que é totalmente diferente. Enquanto o fiador responde pela totalidade da dívida, o avalista responde somente pelo quantum avalizado. Diante disso, seria interessante você criar um mecanismo no teu sistema, informando o que é, se avalista ou fiador. Se fiador, pode protestar junto, avalista não.

Eu faço diferente. Total em cartão R$ 5,00 Total em dinheiro R$ 5,00 Dinheiro recebido R$ 20,00 Troco = Dinheiro Recebido - Total em dinheiro, então troco = R$ 15,00.

No caso de devolução e seu cliente for SN, porem o destinatário, no caso de devolução, for tributação normal, e, houver ICMS, deve ser destacado o ICMS. Isso se faz no caso do emitente da devolução for SN, e, assim sendo, usa-se o CSOSN 900. Informe o pCredSN e vCredICMSSN. Simples assim.

Boa tarde. você leu esse tópico? O Italo deu um passo-a-passo de como fazer.

Os dois. Veja esse tópico. http://www.projetoacbr.com.br/forum/topic/24209-mudanças-nt-2015002-nt-2015003-nf-e-nfc-e-e-componentes-acbr/?page=3

Boa tarde. Ontem um cliente de uma empresa optante do simples nacional, entrou em contato comigo, alegando que, segundo o seu contador, deveria constar no XML o cálculo do imposto e a respectiva alíquota. Lhe respondi informando que, de acordo com o enquadramento tributário da empresa, tal requisição não seria possível. Então enviei o email conforme transcrição: Boa tarde. Segue a análise sobre o e-mail recebido. Sobre os arquivos XML, em princípio, eles estão dentro da normalidade técnica e jurídica. Do ponto de vista técnico, no que diz respeito a alíquotas do ICMS, há alguns aspectos que devem ser observados. Primeiro, no arquivo XML os dados são dispostos em “tags”, isso quer dizer que existe um controle das informações nelas contidas. Nesse sentido, é oportuno entender como é o funcionamento desse mecanismo. O arquivo que analisa as regras de uma nfe, atualmente é denominado “leiauteNFe_v3.10.xsd”, ou seja, é um parâmetro que deverá ser seguido de forma inequívoca. Com base no arquivo “leiauteNFe_v3.10.xsd”, mais precisamente a partir da linha 1.781, são estabelecidas as regras para geração dos dados relativos ao ICMS, conforme demonstrado abaixo apenas três delas: a) "ICMS00" Essa “tag” faz a validade quando a CST é 000, ou seja, tributado integralmente, trazendo dentro do seu escopo as seguintes “sub tags”: "vBC" Valor da base de cálculo; "pICMS" Alíquota do ICMS; "vICMS" Valor do ICMS; "ICMSSN101" - Tributação do ICMS pelo SIMPLES NACIONAL e CSOSN=101, com as seguintes “sub tags”: "CSOSN" = 101; "pCredSN" Alíquota aplicável de cálculo do crédito (Simples Nacional); "vCredICMSSN" Valor crédito do ICMS que pode ser aproveitado nos termos do art. 23 da LC 123 (Simples Nacional); c) "ICMSSN900" Tributação do ICMS pelo SIMPLES NACIONAL, CRT=1 – Simples Nacional e CSOSN=900 – Outras, com as seguintes “sub tags”: "vBC" Valor da BC do ICMS; "pRedBC" Percentual de redução da BC; "pICMS" Alíquota do ICMS; "vICMS" Valor do ICMS; Desse modo, não há o que se falar em destaque do ICMS para empresas optantes do regime simplificado de arrecadação – Simples Nacional, exceto no caso do ICMSSN900 que permite o destaque do referido imposto. Isso ocorre porque as regras estabelecidas no arquivo “leiauteNFe_v3.10.xsd” não estão previstas as regras de destaque do ICMS para as empresas optantes do simples nacional. Assim sendo, não há a possibilidade de haver base de cálculo, alíquota, valor do ICMS para CSOSN 101 e 102, exceto a alíquota e o valor do crédito do ICMS. Sobre o aspecto da legalidade, pode-se observar que, uma vez assinado digitalmente e autorizado o arquivo da NF-e, este não poderá sofrer nenhuma alteração, devendo manter a sua total integralidade. Por fim, os sistemas de contabilidade já estão preparados para esse padrão, é o caso da Mastermaq, da Domínio entre outras. A título de exemplo, a domínio sistemas, em seu manual denominado “Guia de Treinamento Domínio” p.109 a 112, disponível em < http://download.dominiosistemas.com.br/manuais/Importa%E7%E3o%20Padr%E3o.pdf> acesso em 06.02.2017, estabelece quais critérios serão utilizados na importação. Pelo exposto, espero que tenha ficado esclarecido as possíveis dúvidas. Atenciosamente, Agnaldo Prates Possivelmente seja esse o problema que vocês estão enfrentando.

Bem. Existe no fórum, vários links sobre o assunto, como exemplo: 1. As alíquotas envolvidas no calculo, internas e interestaduais, não são as mesmas dos produtos, Correto? R: As alíquotas internas são as mesmas do produto. Porém, as interestaduais mudam, conforme a região. Exemplo, neste link. Se são diferentes, aonde consigo uma lista delas, internas e interestaduais? R: http://www.jornalcontabil.com.br/difal-alteracao-da-partilha-para-2017/ Elas tem validade? ou seja, a cada ano podem ser alteradas ou somente o % de partilha é alterado R: Já existem o cronograma da partilha definida na Emenda Constitucional 87/2015.

Você pode começar estudando o demo do AcBr. Tanto para NF-e quanto para NFC-e. Existem sim diferenças entre os estados. Uns adotam o PAF com NFC-e, outros o SAT também com NFCe, enfim, apensar de algumas diferenças, o projeto em síntese é o mesmo.

Um país em crise, é hora de encontrar soluções. Depois da famigerada cobrança registrada, digo isso porque, se o beneficiário desejar excluir o boleto registrado no banco, não consegue, ou seja, tem que pagar para baixa-lo. Não fosse isso, agora a nova onda. O boleto poderá ser pago em qualquer agência bancária mesmo depois de vencido. Nossa, até parece uma atitude sensata! Mas não é, mais uma vez o beneficiário vai amargar com mais despesas. O que mais chama a atenção, é o fato dessa federação não possuir uma regra rígida para os malditos layouts que os bancos utilizam. Cada banco possui o seu interesse e com isso cria o seu layout adequado à sua necessidade. Por qual motivo a federação não estabelece uma norma em que, os layouts sejam os mesmos para todos os bancos? Ah, cada banco precisa de uma informação específica, e daí? Não seria mais fácil prever essas situações em um layout único? Não! É menos penoso para quem não desenvolve softwares, afinal, desenvolvedor tem uma vida muito tranquila. Se houvesse um layout único, com certeza a comunicação de boletos entre as instituições financeiras era bem mais rápida e mais segura. Ao invés de interpretar alguma coisa, bastava apenas uma simples leitura da origem, do recebimento e pronto. Um dia certamente isso vai mudar. Mais informações em: Mais informações.

Esse erro começou a aparecer agora? Já havia enviado outras devoluções? Exemplo: AcbrNFe1.NotasFiscais.Add.NFe do begin (...) with Ide.NFref.add do refNFe := OnlyNumber(SuaChave); End;

O procedimento certamente se não for o mesmo é parecido. Isso porque a SH deve ser informada no momento que o equipamento é lacrado na intervenção. O procedimento certamente se não for o mesmo é parecido. Isso porque a SH deve ser informada no momento que o equipamento é lacrado na intervenção.

Bem. Eu salvo em pastas separadas, no banco só se for efetivamente enviada.

Gerar sempre não. Será necessário informar o conteúdo dessa tag.

Bom dia. Veja bem. Segundo o que dispõe a Lei Kandir, o imposto faz parte da base de cálculo. ( isso é uma pouca vergonha ), mas então para não ficar muito descarado o roubo, dizem que é o Imposto por dentro, ou seja, a base de cálculo do imposto tem também o imposto. Veja o uma matéria explicando essa pilantragem. http://www.silnev.com.br/ICMSCALCULOPORDENTRO.pdf

Salvo engano é arredondamento. Valor do ICMS, 146,16, no XML 146,17. Use a Função Total := RoundABNT( quant * unitario, 2) , imposto := RoundABNT( ((Total * Aliq)/100),2) Outro detalhe. Observe sobre as regras do DIFAL. Devem estar também no XML

Sim.

ACBrNFE1.Configuracoes.Arquivos->Iniservicos, informe ACBrNFeServicos.ini.

Bom dia. Eu tenho utilizado o Retorno para baixar os títulos dos meus clientes. Não guardo o DV, porem, eu fiz o seguinte. Coloquei na unit para trazer o CNPJ do pagador, com isso, eu consigo pegar o título no banco de dados, ou seja, CNPJ + VENCIMENTO, me trazem o título. Assim não preciso ter exatamente o número. O certo é que, se for cooperativa, as informações mudam. Cooperativa Sicoob é um Layout, Sicredi outro, Bradesco, BB e Caixa Sicoob, outro, em fim, é uma bagunça generalizada.

Bom dia Luciano. Em primeiro lugar, quero lhe dizer que, de forma coincidente, houve a exclusão dos certificados, tanto na leitora quanto no token, conforme seu relato. Eu não acredito que o componente tenha excluído nenhum certificado, isso já foi discutido aqui à exaustão. A questão é lógica. Imagine se cada vez que o componente lesse o certificado ele fosse excluído! Lógico que seria um caos. Mas vamos imaginar o seguinte. Toda mazela deve ser atribuída a alguém ou a algo. O que me intriga é que, muitas pessoas, e, no caso estas certificadoras, não conseguem dar um passo a frente e analisar o que pode estar ocorrendo, o fato é que, de modo algum o componente vai excluir o certificado. Como assim? Simples. Certificados A1, alguém já teve notícia sobre sua exclusão? Eu particularmente não! Por outro lado, é público e notório que, no Brasil as coisas são feitas em benefício de uns em detrimento a outros. Imagine o seguinte, se todos os desenvolvedores unissem e solicitassem que seus clientes requisitassem somente o certificado A1, certamente haveria um movimento encabeçado pelas certificadoras de que, o A1 não seria seguro, justamente para quê? Simples, aumentar o faturamento, e de forma irresponsável. Quem pode garantir que isso não seja uma maneira de obrigar "alguém" a comprar outra porcaria de certificado A3? Se fosse séria a questão, a própria Receita Federal, ente da administração pública direta, teria na sua página no e-CAC uma forma do cliente, ao acessar o portal, emitir um certificado válido. Mas não, alimenta esse comércio podre de gente gananciosa e irresponsável protegidas pelo manto da "legalidade". Por tudo isso, eu afirmo categoricamente, o ACBr não exclui nenhum certificado, é fácil atribuir a responsabilidade a terceiros. Diante disso, todos os certificados dos meus clientes que estão vencendo, estou aconselhando-os a fazerem um A1.