Painel de líderes

Bom dia @AllyRafhiyy E N Nunes Em regra geral temos a redução de base de calculo de duas formas: 1 - Redução direta: Multiplicar o percentual de redução pela base pela base de cálculo, e deduzir o resultado, como você fez: vBC = 100,00 pRedBC = 10% Base reduzida = 100,00 - 10% = 90,00 2 - Redução de base para equiparação de alíquota: Reduzir a base de cálculo de forma que equipare alíquota de 17% para 7%: 100% dividido pelo percentual da alíquota da operação, o resultado multiplicar pela carga tributária (percentual). O resultado encontrado será o percentual tributado dentro de 100% Ex: De 17% para 7% = 100% / 17% = 588, 2352 x 7% =41,18% (este é o percentual de redução a aplicar na base cheia) Fora desses dois casos, sugiro pedir a base legal para qualquer alteração em seu sistema.

Boa Tarde, Testei a Emissão e Consulta Lote por RPS está funcionando. Referente ao cancelamento consegui indentificar o problema. Ao fazer o cancelamento da NFSe recebi o seguinte XML. <ns1:CancelarNfseResponse> <CancelarNfseResult> <CancelarNfseResposta xmlns="http://www.abrasf.org.br/nfse.xsd"> <RetCancelamento> <NfseCancelamento versao="2.04"> <Confirmacao Id="166"> <Pedido> <InfPedidoCancelamento> <IdentificacaoNfse> <Numero>6</Numero> <CpfCnpj> <Cnpj>12345678910</Cnpj> </CpfCnpj> <InscricaoMunicipal>46456</InscricaoMunicipal> <CodigoMunicipio>4204202</CodigoMunicipio> </IdentificacaoNfse> </InfPedidoCancelamento> <CodigoCancelamento>1</CodigoCancelamento> </Pedido> <DataHora>2022-12-28</DataHora> </Confirmacao> </NfseCancelamento> </RetCancelamento> </CancelarNfseResposta> </CancelarNfseResult> </ns1:CancelarNfseResponse> Esse xml é o pedido de cancelamento lá na SigCorp Se Consultar o RPS novamente e olhar o xml veja que existe uma tag nova dentro do mesmo - <NfseCancelamento versao="2.04"> - <Confirmacao Id="166"> - <Pedido> - <InfPedidoCancelamento> - <IdentificacaoNfse> <Numero>6</Numero> - <CpfCnpj> <Cnpj>12345678910</Cnpj> </CpfCnpj> <InscricaoMunicipal>46456</InscricaoMunicipal> <CodigoMunicipio>4204202</CodigoMunicipio> </IdentificacaoNfse> </InfPedidoCancelamento> <CodigoCancelamento>1</CodigoCancelamento> </Pedido> <DataHora>2022-12-28</DataHora> </Confirmacao> </NfseCancelamento> Essa tag é a confirmação do cancelamento, parece que o acbr não está interprentando ela. Complementando se pegar o link que gera para baixar o PDF vai ver que vem com a marca d' agua, cancelada

Boa Tarde! Testando hoje, na cidade Avaré, não consegui mais cancelar a nota. Ontem a tarde estava cancelamento normalmente, apenas não retornava a informação do cancelamento, tinha que consulta a nota pra saber. Talvez o pessoal da sigcorp tenha quebrado mais alguma coisa....

Boa tarde Icozeira, No programa exemplo, mais precisamente na procedure que configura o componente basta trocar o zero por -1. veja: // A propriedade CodigoMunicipio tem que ser a ultima a receber o seu valor // Pois ela se utiliza das demais configurações with ACBrNFSeX1.Configuracoes.Geral do begin LayoutNFSe := TLayoutNFSe(cbLayoutNFSe.ItemIndex); CodigoMunicipio := StrToIntDef(edtCodCidade.Text, -1); <=== trocar o zero por -1 end; Ao executar pela primeira vez, vai ocorrer um erro de cidade não existente, click em Ok para continuar, o combo vai ser preenchido com as cidades. Esse erro só vai ocorrer quando for a primeira vez, depois não corre mais, mesmo se você trocar a cidade configurada por outra.

@willian_delan Correção enviada na Rev-28014. Por favor, atualize seus fontes, reinstale o ACBr e teste novamente.

Bom Dia ! O problema era a falta das dll. Obrigado pelo apoio

Olá Pessoal, Mais uma notícia "boa" para o início do próximo ano.. E quais são as novidades? Não poderia ser diferente, e claro, são Alterações no Layout e regras de validação da NF-e/NFCe e também alguns novos códigos de rejeição. Quanto aos novos campos Inclusão de campo destinado a informar NF-e referenciada em sigilo Aumento do número de documentos referenciados. Quanto as regras de validação Removidas regras relativas as restrições para emissão de NFe por pessoa física Corrigida validação do CNPJ do Resp. Técnico para ser aplicada somente se existir informação par a tag no XML Alterada para ser a critério da UF a aplicação da regra de validação do Regime Tributário informado bate com cadastro na SEFAZ, inclusive com novos códigos de rejeição Inclusão de regras garantido a consistência da NFe Referenciada Inclusão de restrições quanto a referencia de NFCe Inclusão de restrições relativas as operações permitidas para NFe emitida por não contribuintes do ICMS Inclusão de validação quando o FCP for obrigatoriamente 0 conforme tipo de operação (adoção a critério da UF) Quanto aos Código de Rejeição 951 - Rejeição: Chave de Acesso referenciada com código numérico zerado não permitida para finalidade diferente de normal. 952 - Rejeição: Chave de Acesso referenciada com a mesma Chave Natural da Nota Fiscal atual 953 - Rejeição: Informado ECF referenciado para CFOP 5.929 em UF que não permite essa referência 475 - Rejeição: Operação não permitida para não contribuinte 474 - Rejeição: FCP não deve ser destacado na NF-e conforme legislação estadual Sobre a aplicação na NFe e NFCe Em relação as regras de validação, somente a regra relativa a validação do CNPJ do Responsável Técnico(ZD02-10) e a regra relativa ao Código do Regime Tributário-CRT (7C21-10) se aplicam a ambos os documentos, as demais são exclusivas para NFe. Sobre as regras a critério da UF Este tipo de regra sempre causa dúvidas, afinal tira o padrão nacional daquela informação, nesta NT tivemos a inclusão dos campos que permitirão a informação de documento referenciado, porém sem informar a chave do mesmo, no caso, a tag refNFeSig, que somente poderá ser adotada após as UFs publicarem sua regulamentações internas. Mas para esclarecer a motivação da inclusão desta tag, conversamos com a AFRAC e fomos informados de que se deve ao fato de que em alguns setores acontece venda triangular, e dado a haver a chave do documento recebida pelo cliente, ele acaba tendo informações sobre o valor pago anteriormente pelo seu fornecedor, gerando desconforto entre as partes. Quanto a vigência da NT Ambiente de Homologação: 07/02/2023 Ambiente de Produção: 03/04/2023 Sobre as mudanças nas soluções ACBr Por se tratar de inclusão de novos campos e alteração na quantidade máxima de documentos referenciados, será necessário adequações no Componente, assim como no ACBrMonitorPlus e a ACBrLib, tais alterações serão enviadas ao SVN a tempo da SEFAZ liberar o ambiente de homologação com estas mudanças. Naturalmente que havendo a inclusão de novas informações, também se fará necessário algum grau de adequação da aplicação, conforme o segmento na qual a mesma é utilizada. Até aqui tivemos um breve resumo dos pontos trazidos por esta NT, mas para se aprofundar melhor, recomendamos que continue a leitura até o final do artigo. 1. Alterações do layout Inclusão do Referenciamento de NF-e por Chave com código numérico zerado (Campo: refNFeSig). Criação de campo específico no grupo de Documento Fiscal Referenciado (NFref) para permitir ao contribuinte referenciar Nota Fiscal Eletrônica, modelo 55, informando a Chave da NF-e com o código numérico zerado. Essa alteração visa garantir a manutenção do Sigilo Fiscal da NF-e referenciada. Importante A utilização deste campo fica restrita a situações previstas em legislação específica de cada UF. A referência pela chave de acesso completa (campo: refNFe) continua obrigatória nos casos de NF-e de devolução, complementar e quando a legislação exigir. Cuidados quanto as tags refNFe e refNfeSig Os campos refNFe e refNFeSig não podem constar ao mesmo tempo no XML, ou seja, ou ele contém o campo refNFe ou o campo refNFeSig. Alteração do número máximo de ocorrências do grupo de Documentos Fiscais Referenciados (tag: NFref) O grupo de Documentos Fiscais Referenciados (tag: NFref) passou de um máximo de 500 para 999 ocorrências, para atender situações em que era necessário referenciar mais que 500 documentos numa mesma NF-e. 2. Alterações de Regras de Validação Criação das Regras de Validação garantindo a consistência da Chave Referenciada BA02a-10, BA02a-20, BA02a-30, BA02a-40, BA02a-50, BA02a-60, BA02a-70, BA02a-80, BA02a-90, BA02a-100 Essas regras visam garantir a consistência da Chave Referenciada com código numérico zerado (tag: refNFeSig) além de evitar que esse referenciamento aconteça em uma NF-e com finalidade diferente de normal. Remoção das Regras de Validação quanto a emissão de NF-e por Pessoa Física C02a-04, C02a-08, C02a-14 Atualmente existe um controle das SEFAZ no credenciamento individual para emissão da Nota Fiscal pelos Contribuintes Pessoa Física (CPF). Eliminadas as Regras de Validação que controlam a opção da UF em aceitar ou não a emissão de Nota Fiscal para os Contribuintes emitentes Pessoa Física. Criação da Regra de Validação destinada a rejeitas referenciamento de NFC-e na NF-e I08-186 O objetivo desta regra é impedir o referenciamento de ECF em uma NF-e com CFOP 5929 ou 6929, uma vez que em algumas unidades federadas o ECF já foi completamente substituído por NFC-e e não existe mais a possibilidade de seu referenciamento para estas operações. Alteração das Regras de Validação quanto as operações permitidas para Não Contribuintes do ICMS I08-194 e I08-198 Algumas SEFAZ concedem IE para não Contribuinte do ICMS, mas limitam a emissão de NF-e de venda unicamente pelo Emissor de Nota Fiscal Avulsa disponibilizado pela própria SEFAZ. Alteração da Regra de Validação quanto a forma de informar os valores de FCP N17c-30 Conforme a legislação estadual, algumas SEFAZ controlam a informação dos valores vinculados ao Fundo de Combate à Pobreza (FCP) no processo de apuração do imposto, impedindo essa informação individualizada em cada NF-e. Alteração da Regra de Validação quanto ao CNPJ do Responsável Técnico somente se houver a informação ZD02-10 Melhorada a documentação da RV, efetuando a validação unicamente se a informação do CNPJ do Responsável Técnico for informada. Criação da Regra de Validação para validar a existência na base de dados da UF emitente do documento relativo a chave referenciada 3BA02a-10 Regra de validação para verificar a existência da Chave Referenciada com código numérico zerado na base de dados de NF-e da UF emitente do documento. Alteração da Regra de Validação quanto a informação do Código de Regime Tributário informado no XML 7C21-10 A RV 7C21-10 controla a informação na Nota Fiscal do CRT ou CSOSN, conforme o cadastro do Contribuinte na SEFAZ. Alterada esta Regra de Validação para ser opcional por UF.

Tem como incluir no AcbrNFSeXServicos.ini [3502200] ; Atualizado em 27/12/2021 Nome=Angatuba UF=SP Provedor=iiBrasil Versao=2.04 ProRecepcionar=https://api.iibr.com.br/3502200/1/soap/producao/rps HomRecepcionar=https://api.iibr.com.br/3502200/1/soap/homologacao/rps Conforme explicações no site : https://angatuba.iibr.com.br/dev/dev_dashboard.php#dev_ws_notafiscal$$ZDhiOTM1MzlmNmEzNDA3ZGUzY2U4YmZmZWE0OWE3ZDhaRGhpT1RNMU16bG1ObUV6TkRBM1pHVXpZMlU0WW1abVpXRTBPV0UzWkRnek5qRT0=$$li_361_3$$3 Para iniciarmos os testes . Obrigado Desde ja Adilson Pazzini

Olá Pessoal, Um cliente meu utiliza o sistema em um Terminal Service e na impressão de NFCe visualizando em Tela, TACBRNFeDanfeCeFortes Ao imprimir o QRCode da NFCe sai da seguinte forma: Borrado e não dá para fazer a leitura. Quando imprime do PDF, mas dentro do Terminal Service também a impressão sai correta: Isso ocorre somente no Terminal Service. EscPos não consigo imprimir, ocorre o seguinte erro Problema ao imprimir: EInOutError: I/O error 67 Alguém tem alguma sugestão do que posso fazer ou testar ? Desde já obrigado.

Mandei e-mail do xml pra eles analisarem e estou aguardando. Mas consegui emitir a nota pelo ACBr fazendo o seguinte: Não enviei as tags de RPS: E coloquei pra passar as tags de data prestação de serviço mesmo estando como opcional no manual: Já está no portal de testes do cliente: Agora vou comentar com o provedor oq é correto e ver oq eles falam.

Não, não tem problema não.. se quiser anexar a classe com essa alteração, podemos subir para o svn..

Mais um complemento sobre o cancelamento, fiz um teste em produção. Ele cancelou a nota, mas não deu retorno, e quando consulta o status da nota ele fala que está emitida...

Perfeito, muito obrigado.

Deu certinho! Obrigado, Pedro!

boa tarde...a configuração é a mesma dos outros bancos.. a diferença é que tem os arquivos dos certificados... minha rotina é assim FACBRBoleto.Configuracoes.WebService.ArquivoCRT := FCarteira.ArquivoCRT;// 'E:\\INTER\\Certificados\\Inter API_Certificado.crt'; FACBRBoleto.Configuracoes.WebService.ArquivoKEY := FCarteira.ArquivoKEY;//'E:\\INTER\\Certificados\\Inter API_Chave.key'; FACBRBoleto.Configuracoes.WebService.SSLHttpLib := httpOpenSSL; FACBRBoleto.Configuracoes.WebService.SSLHttpLib := httpOpenSSL; FACBRBoleto.Configuracoes.WebService.SSLCryptLib := cryOpenSSL; FACBRBoleto.Configuracoes.WebService.SSLXmlSignLib := xsLibXml2; FACBRBoleto.Configuracoes.WebService.SSLType := LT_TLSv1_2; FACBRBoleto.Configuracoes.WebService.UseCertificateHTTP := false; FACBRBoleto.Configuracoes.WebService.TimeOut := 10000; FACBRBoleto.Configuracoes.WebService.ArquivoPFX := FCarteira.CERTIFICADO_DIGITAL; FACBRBoleto.Configuracoes.WebService.Senha := FCarteira.SENHA_CERTIFICADO

Certo, vou falar com eles, obrigada por enquanto.

A nova Tabela de Códigos de Benefícios Fiscais (cBenef) já está disponível no site da Economia, porém só será obrigatória a partir de 1º de março de 2023 Prevista para ser obrigatória em janeiro, a vigência da Tabela de Códigos de Benefícios Fiscais (cBenef) foi adiada para março de 2023. A mudança é para as empresas que gozem de qualquer benefício fiscal de ICMS e emitem Nota Fiscal Eletrônica (NF-e) ou Nota Fiscal de Consumidor Eletrônica (NFC-e). De acordo com o gerente de Informações Econômico-Fiscais (Gief), Luciano Pessoa, o decreto que formalizará o adiamento está previsto para ser publicado em janeiro. Com a mudança os contribuintes terão mais tempo para se prepararem. Tendo em vista que praticamente todas as empresas contam com algum tipo de benefício fiscal, a Secretaria da Economia já está executando o procedimento para que todas possam se adaptar a tempo. A “Tabela de Códigos de Benefícios Fiscais”, estabelecida pela Instrução Normativa 1.518/22-GSE, está disponível no site da Economia. “Quem quiser informar o código de benefício fiscal já pode informar, não tem problema. Está funcionando perfeitamente. É importante aderir antes para que em março esteja em pleno funcionamento”, frisou o coordenador de notas fiscais da Gief, Antônio Godoi. Após o período de testes, em janeiro e fevereiro, a partir de 1º de março de 2023 as empresas do Estado de Goiás que forem emitir as notas estão obrigadas a preencher o campo cBenef com o respectivo código. Para acessar, basta entrar no site da Economia e, em seguida, clicar em “Documentos Fiscais” no campo esquerdo do site. Na sequência, clicar no banner “Códigos de Benefícios Fiscais”. Sanções: A inobservância da exigência do preenchimento do código cBenef, a partir de 1º de março, acarretará ao contribuinte fiscalização e a penalidades. É preciso estar atento à forma de preenchimento e garantir que o código utilizado esteja de acordo com a legislação para que não ocorra rejeição das notas fiscais em decorrência do preenchimento equivocado. Caso o campo não seja preenchido, haverá a rejeição da nota e a empresa ficará impedida de emitir o documento fiscal. Os benefícios fiscais são: Não Incidência (incluindo Imunidade), Isenção e Redução de Base de Cálculo. Saiba Mais: O Código de Benefício Fiscal é uma sequência de letras e números, iniciados pela sigla da UF em questão, que tem por objetivo identificar em qual grupo de Benefício Fiscal aquele item se enquadra. Eles devem ser utilizados de acordo com o CST (Código de Situação Tributária) correspondente. Fonte: https://www.economia.go.gov.br/noticias/8553-economia-prorroga-obrigatoriedade-de-informação-do-código-de-benefício-fiscal-na-nota.html?highlight=WyJjXHUwMGYzZGlnb3MiLCJkZSIsImJlbmVmXHUwMGVkY2lvcyIsImZpc2NhaXMiLCJjXHUwMGYzZGlnb3MgZGUiLCJjXHUwMGYzZGlnb3MgZGUgYmVuZWZcdTAwZWRjaW9zIiwiZGUgYmVuZWZcdTAwZWRjaW9zIiwiZGUgYmVuZWZcdTAwZWRjaW9zIGZpc2NhaXMiLCJiZW5lZlx1MDBlZGNpb3MgZmlzY2FpcyJd

Enviado e-mail.

Boa tarde Juliomar, eu também desconfio, foi só uma duvida da equipe de qualidade da empresa onde eu trabalho, obrigado.

Bom dia Willian, Com certeza foi erro de digitação, vou fazer a correção e enviar para o SVN.

Bom dia! Para complementar o que o marcopoloviana comentou, quando um produto é beneficiado por uma redução, deve constar na nota, em informações adicionais a previsão legal para este cálculo. Estas informações você deve pegar com o escritório contábil. Ao ter a informação em mãos, estude ela (art. da legislação aplicada e suas regras) que te ajudará a compreender o que precisa ser feito.

Bom dia, respondendo os amigos, sim não uso delphi, uso a plataforma dot.net Segue o arquivo INI, estou preenchendo todos os dados, claro que enviando com os valores zerados no caso das bases e aliquotas, mas inclusive as tags referente a combustivel todas preenchidas segue o arquivo ini segue o xml assinado A rejeição apresentada é XMotivo=Rejeicao: Nao informada vBCSTRet, pST, vICMSSubstituto e vICMSSTRet [nItem:1] NFe.INI 43221292176288000178550050000030131000005692-ERRO.xml

Bom dia @Ronaldo Souza! Por favor, você seguiu a orientação do Italo e reinstalou o ACBr após realizar a atualização dos fontes?(Se possível, por favor, peço que faça esse processo novamente, dessa vez marcando a opção para "Apagar arquivos antigos"). De fato, a AplicarXMLToUTF8 adiciona a declaração de <?xml version="1.0" encoding="UTF-8"?>. E a declaração <?xml version="1.0" encoding="ISO-8859-1"?> é adicionada posteriormente via hardcode. Mas por favor, note a RemoverDeclaracaoXML(ListaRps). A mesma remove a linha <?xml version="1.0" encoding="UTF-8"?>! Ela aparece no soap porque é adicionada de novo na procedure que salva o arquivo, mas no envio, ela vai apenas com uma declaração. Você pode confirmar isso testando pelo programa exemplo, colocando um ponto de parada na procedure Executar na linha 942 da unit ACBrNFSeXWebServiceBase.pas e verificando o valor da variável FPEnvio.(Ou Message se preferir). Testando aqui, usando o programa exemplo e fazendo o envio para a cidade de Araras estou recebendo o retorno 401 Unauthorized, mas isso é o esperado, pois não tenho dados válidos de um prestador.

ambiente de homologação via Webservice falho a memoria tem dados especificos e se repete algo assim. ou é o PIX, mas tem alguma coisa assim pois é um sandbox

então no caso nesses clientes ainda poderia estar em uso o arquivo e ao mesmo tempo tentar assinar. por isso a sugestão. mas melhor que isso seria tu usar os ini do monitor . lhe pouparia muito tempo

Aumentar o timeout não deveria parar de funcionar algo, tem algum problema de ambiente ainda. Confirme se está usando: * winCrypt * Tls 1.2 * Todas as atualizações do Windows feitas * Driver da leitora atualizado É o melhor a fazer, o A3 é uma praga e com A1 poderá utilizar OpenSSL sem depender mais de nada do Windows.

Pensei uma coisa e escrevi outra, a inscrição municipal incorreta para o respectivo erro é a do prestador e não do tomador.

Aqui consegui emitir, consultar e cancelar. Porém está com problema no retorno do cancelamento, a nota está sendo cancelada na prefeitura, mas não está retornando. Se consulta a nota após o cancelamento ele retorna que está cancelada.

Boa Tarde! Consegui fazer a emissão utilizando o metódo enviar passando o parametro meUnitario

Perfeito, obrigado pela ajuda consegui rodar aqui. Já estou em contato com a Aline para fazer minha assinatura. Uma ultima informação. O sistema retorna esta mensagem, isso significar que foi enviado ou que teve algum problema. Obrigado

Boa tarde, Foi publicada em 26/12/2022 a Instrução Normativa 108/2022, a qual trouxe pequenos ajustes visando esclarecer melhor a integração entre os pagamentos eletrônicos e os documentos fiscais. A seguir as diferenças com as mudanças destacadas em vermelho e textos removidos em tachado Esclarecimento sobre as Operações afetadas (Artigo 29.5.1) A emissão do comprovante de transação ou intermediação de vendas ou serviços, realizados de forma presencial, efetuada com cartões de débito, de crédito, de loja ("private label"), transferência de recursos, transações eletrônicas do Sistema de Pagamento Instantâneo e demais instrumentos de pagamento eletrônico, deve estar vinculada à NFCe emitida na operação ou prestação, mediante interligação com o programa emissor do documento fiscal Sobre as Obrigatoriedades (Artigo 29.5.1 b) b) 01/07/23, para os demais estabelecimentos emissores de NFC-e. Sobre as Informações Mínimas no Comprovante de Transação (Artigo 29.5.1.3 - Itens b e c) b) número da autorização junto à instituição de pagamento código da autorização ou identificação do pedido c) identificador do terminal em que ocorreu a transação, nos casos em que se aplica Sobre o envio das Informações pelos Bancos (Artigo 1.1.4 - Itens g e h) g) para os meses de julho a setembro julho e agosto de 2023, até o último dia de outubro de 2023; h) para outubro setembro de 2023 e meses subsequentes, conforme prazo estabelecido no "caput" do item 1.1 Fonte: http://www.legislacao.sefaz.rs.gov.br/Site/Document.aspx?inpKey=292768&inpCodDispositive=&inpDsKeywords=108