Painel de líderes

Olá pessoal, Disponibilizada Impressão e Download XML do BP-e A consulta pública do BP-e do portal DF-e da SVRS conta agora com a opção de Download do XML do BP-e para o certificado digital do emitente do BP-e e ainda a impressão do documento. Para realizar a Consulta Pública de um BP-e clique aqui.

Olá pessoal, Aproveitando os últimos minutos do segundo tempo, temos novidades para o inicio do ano que vem. Novidades da versão 1.40 da NT 2019/001 * Modifica a RV N12-94 para deixar mais específica a rejeição, criando assim a RV N12-98 com sua respectiva rejeição; A regra vai ser ativada a partir de 11/05/2020 10/08/2020 em produção, verificando a existência e a vigência do cBenef. Assim, a RV N12-94, a partir dessa data, passará a verificar apenas se o cBenef é compatível com o CST. Essa nova regra permite que determinada UF possa validar apenas a existência do cBenef, caso não opte por validar a compatibilidade com o CST. A criação da RV N12-98 não traz impacto para os sistemas emissores que já estão preparados para a validação da RV N12-94, salvo o possível tratamento da mensagem da rejeição. Rejeição 946: Informado código de beneficio fiscal incorreto ou inexistente na UF. * Adiciona as exceções e modelos para as RV N12-85, N12-86, N12-90, N12-94, N12-97 e N12-98; Criação de Exceções para as Regras de Validação N12-85 (Se informado CST e não informado código de benefício fiscal), N12-86 (Se informado CST e informado código de benefício fiscal), N12-90 (Se CST de ICMS = (20, 30, 40, 41, 50, 70 ou 90)), N12-94 (Se informado CST e informado código de benefício fiscal), N12-97 (Não informados campos de valores do CST 51 (Diferimento)) e N12-98 (Se informado código de benefício fiscal) Trata-se de exceções que já haviam sido criadas e implementadas, tendo sido comunicadas por meio de aviso disponibilizado no Portal Nacional da NF-e. As Rejeições das Regras de Validação N12-85, N12-86, N12-90, N12-94 e N12-97 encontram-se no artigo referente a NT2019/001 versão 1.30 * Informa as Exceções e Datas aplicáveis as UF que ativaram as RV N12-85, N12-86, N12-90, N12-94 e N12-97; e que ativarão a N12-98; Quadro com datas de ativação das RV, respectivas exceções e possíveis modelos para UF que ativaram/estão ativando tais RV. Quadro já disponibilizado no Portal da NF-e. A única diferença é a indicação das opções de modelos (55; 65; ou 55/65). Tal quadro demonstra quais UF estão ativando as RV, bem como as exceções aplicadas e os modelos que de DF-e (55 e 65) em que se aplicam a tais RV. A tabela a seguir substitui a do item anterior (1.8), pois adiciona exceções e modelo aplicável. Na tabela a seguir encontram-se as Unidades da Federação que implementarão as Regras de Validação N12-85, N12-86, N12-90, N12-94, N12-97 e N12-98, previstas nesta Nota Técnica. Na legenda são encontradas as datas de aplicação, as exceções e os modelos aplicáveis (55/65), a critério da UF. Regra de validação - Aplicação e Exceções +----------------------------------------------------------------------------------------------------------+ | UF | N12-85 | N12-86 | N12-90 | N12-94 | N12-97 | N12-98 | +----------------------------------------------------------------------------------------------------------+ | PR | (D1), (55/65) | (D1), (55/65) | (D*) | (D2), (55/65) | (D1), (55/65) | (D3), (55/65) | +----------------------------------------------------------------------------------------------------------+ | RJ | (D2), (55/65) | (D2), (55/65) | (D2), (55/65) | (D2), (55/65) | (D2), (55/65) | (D3), (55/65) | | | (E2, E3) | (E2, E3) | (E2, E3) | (E2, E3) | (E2, E3) | (E2, E3) | +----------------------------------------------------------------------------------------------------------+ | RS | (D2), (55/65) | (D2), (55/65) | (D*) | (D*) | (D*) | (D3), (55/65) | | | (E3,E4) |(E3,E4) | | | | (E3,E4) | +----------------------------------------------------------------------------------------------------------+ |Demais UF | (D*) |(D*) | (D*) | (D*) | (D*) | (D*) | +----------------------------------------------------------------------------------------------------------+ Datas para aplicação das Regras de validação (D), com respectivo Modelo de DF-e: (D*) - Regra de validação não será aplicada; (D1) - Aplicação a partir de 02/09/2019; (D2) - Aplicação a partir de 01/10/2019; (D3) - Aplicação a partir de 11/05/2020 10/08/2020 em Produção (Homologação: 16/03/2020) Aplicação aos Modelos de DF-e: (55); (65); ou (55/65) Exceções constantes nas Regras de Validação, a critério da UF: (E1) - Exceção 1: a RV não se aplica quando Finalidade de emissão da NF-e (tag: finNFe) igual a Devolução de Mercadoria e Identificador de local de destino da operação (tag: idDest) igual a Operação interestadual ou com o Exterior. (E2) - Exceção 2: a RV não se aplica quando Finalidade de emissão da NF-e (tag: finNFe) igual a Devolução de Mercadoria; (E3) - Exceção 3: a RV não se aplica quando Finalidade de emissão da NF-e (tag: finNFe) igual a NF-e de ajuste; (E4) - Exceção 4: a RV não se aplica quando Tipo de Operação (tag: tpNF) igual a Entrada. Observação: A Exceção 1, constante nas respectivas Regras de Validação, aplica-se a todas as UF. Assim, não necessita estar no quadro acima. As datas aqui definidas, juntamente com todas as demais informações a respeito das regras de validação opcionais por UF, podem ser consultadas em tabela publicada no Portal Nacional da NFC-e, na área “Regras de Validação” da aba “Desenvolvedor”. Para contribuintes estabelecidos no Estado do Rio Grande do Sul, as Regras de Validação N12-85 e N12-86 permitirão informar qualquer CST até 31/03/2020 no ambiente de autorização em produção, conforme tabela disponibilizada no Portal da NF-e. Em homologação, o contribuinte já pode testar a validação dessa Regras. A RV N12-94 será desativada para o Rio Grande do Sul a partir da publicação desta NT.  A RV N12-98 será ativada conforme as datas de homologação e produção previstas nesta NT. * Retira o modelo 65 da validação da RV B03-10 Datas de efetivação das modificações: Ambiente de Homologação: 16/03/2020 Ambiente de Produção: 11/05/2020 (10/08/2020) Como se tratam de regras de validação nos WebServices das SEFAZ-Autorizadoras, não se faz necessário nenhuma alteração nos fontes dos componentes e nem na aplicação. Para baixar a NT na integra favor acessar a nossa biblioteca.

Bom dia Pessoal! Tive as seguintes respostas da SEFAZ: Sergio Pinetti por gmail.com 27 de dez. de 2019 15:13 (há 3 dias) para Thiago, Felipe, Ana Prezada Ana Paula, Em relação ao Erro 1003, identificamos que sua origem está na integração de alguns serviços do Sistema S@T com sistemas de responsabilidade da Secretaria da Receita Federal do Brasil. Um dos componentes do cadastro de contribuintes do ICMS de Santa Catarina acessa, para fim de validação, o sistema da SRFB que há alguns dias retorna erro devido a sua indisponibilidade. Observou-se ainda que esta intercorrência afeta outros serviços do Sistema S@T, além dos componentes do Sistema SIV que recebem, validam e processam os arquivos eletrônicos XML do Bloco X. Durante esta tarde os técnicos responsáveis pela manutenção e suporte do Sistema S@T tentarão implementar solução de contorno a fim de remover essa validação de dados realizada com base nos sistemas de responsabilidade da Secretaria da Receita Federal do Brasil. Assim, em relação aos bloqueios previstos na legislação aplicável aos requisitos técnicos do Programa Aplicativo Fiscal PAF-ECF solicitamos não implementa-los nos pontos de venda em razão da rejeição dos arquivos do Bloco X estar ocorrendo indevidamente conforme descrito. Everton Telles <[email protected]> 27 de dez. de 2019 16:16 (há 3 dias) para Marcos, GUSTAVO, Sergio, Ana Prezados, foram realizadas devidas correções. Ana Paula, persistindo o problema por favor nos avise. Obrigado pela ajuda. Everton Telles Auditor Fiscal da Receita Estadual Secretaria de Estado da Fazenda de Santa Catarina Diretoria de Administração Tributária - DIAT Gerência de Sistemas e Informações Tributárias - GESIT Telefone: (48) 3664-5406 Voip 018-45406 Segundo eles já está resolvido.

Encontrei o erro, é no nosso software mesmo, muito obrigada!

Bom dia pessoal, No dia de hoje a SEFAZ-MS publicou no DOE, o decreto 15.341, o qual regulamenta o Programa Nota MS Premiada e entre outras coisas, define que as dezenas para o sorteio deverão ter sua impressão obrigatória a partir de 01/02/2020. Conforme pode ser observado na transcrição abaixo, durante o tempo em que a obrigação não é obrigatória, os cidadãos já estarão participando dos sorteios. Art. 20. A impressão das dezenas nos documentos auxiliares das notas fiscais eletrônicas, na forma desta seção, será obrigatória a partir de 1º de fevereiro de 2020. § 1º A falta da impressão das dezenas, na forma prevista nesta seção, não impede o consumidor, que optou por informar o CPF no documento fiscal, de participar do sorteio, observadas as disposições do Capítulo IV deste Decreto. § 2º Na hipótese do § 1º deste artigo, as dezenas geradas para o respectivo documento fiscal poderão ser consultadas no Portal da Nota MS Premiada na internet, disponível no endereço eletrônico www.notamspremiada.ms.gov.br. NO tópico abaixo temos mais detalhes sobre como os contribuintes foram comunicados sobre o programa, além do histórico de alterações nos componentes ACBr. Fonte: http://www.icmstransparente.ms.gov.br/index.aspx?sf=http://arq.sefaz.ms.gov.br/inicio/legislacao.asp

Bom dia Muito obrigado pela alteração @Italo Jurisato Junior

Bom dia, Favor atualizar os fontes, note que fiz alterações nos arquivos: Cidades.ini e ISSNet.ini Acredito que dessa forma vamos manter compatibilidade com todas as cidades atendidas por esse provedor.

Bom dia. Versão do ACBrMonitorPlus com este requisito já está disponivel para download. Att.

O responsável pela compilação é o nosso servidor de build eu vou ver com o @Daniel Simoes o que pode estar ocorrendo

Bom dia Fernando, Muito obrigado pela colaboração, já foi enviando para o repositório.

Bom dia. já chegou a olhar o svn que fez o checkout? tem uma pasta chamada exemplos, lá todos os componentes tem algum exemplo de uso

Bom dia Camilo, Existe uma tabela geral que todos municípios deveria seguir, mas sabe como é. A cidade de São Paulo por exemplo utiliza uma codificação diferente da tabela. Essa tabela se encontra no formato TXT na pasta: ...\Exemplos\ACBrDFe\ACBrNFSe\Delphi com o nome TabServicos

ha certo obrigado

Italo, Gr@c@, Muito obrigado pela atençao de vcs. Consegui resolver, eu sempre instalei marcando a opçao "Deixar somente a patasa libxx no library patch do delphi", porem ele estava deixando a lib21 e todas as demais do acbr, instalei sem selecionar essa opçao e finalmente deu certo.

Boa tarde Pessoal, Alguns cliente começaram a reclamar de erro ao gerar o xml, nesses casos são os cliente que ja salvam o xml e pdf na rede, quando mudo a configuração para salvar local funciona normalmente. Isso acontece tanto com servidor windows como linux com samba. Fiz teste no meu micro e tudo normal até que mandei o windows verificar atualizações, tinha atualizações pendentes mandei atualizar e reiniciei e comecou a dar aqui tambem, vou postar o erro aqui para ver se ja aconteceu com alguem. Vou depurar aqui para tentar achar o problema, mas se algum já passou por isso e resolveu me dá um toque. Tenho certeza que deve ter alguma novidade do compatilhamento windows que esta forçando o erro. erro: Cannot Create File xxxxx Função incorreta O arquivo é até criado corretamente mas o delphi retorna erro.

Perfeito, funcionou. Tinha que setar lá no cedente. Muito obrigado. DEUS o abençoe. Feliz ano novo a todos.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Boa tarde, Italo. Ajudou sim. Deu certo. Muito obrigado.

Boa tarde Rafael, foi ao ponto, como esta inicializando toda hora, dava a mensagem de erro, problema resolvido Obrigado

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Já precisei pegar o IMEI JTelephonyManager obj := TandroidHelper.Activity.getSystemService(TJContext.JavaClass.TELEPHONY_SERVICE); if obj <> nil then begin tm := TJTelephonyManager.Wrap( (obj as ILocalObject).GetObjectID ); if tm <> nil then v_imei := JStringToString(tm.getDeviceId); end;

Uma dúvida minha tu começou agora com questões fiscais? se sim deve ler todas a NT de manuais de nota. além de pesquisar aqui no fórum. vale lembrar que seu tópico saiu da instalação para o exemplo e já está na parte de emitir, deve se tratar um tópico por assunto , mas as suas dúvidas pelo que percebo com uma pesquisa aqui no fórum vai sanar todas elas. Sim tu precisa de CNPJ e certificado para emitir tanto em homologação, que serve para tu testar tudo quanto para quando por em Produção.

Guilherme, Fiz uma alteração visando atender essa condição (Contribuinte = Simples Nacional) gera a tag Alíquota mesmo valendo zero. Já se encontra o repositório, favor atualizar os fontes e faça novos testes.

Bom dia Marcio, Já fiz a alteração e já vou enviar para o repositório. Da próxima vez procure postar no tópico exclusivo para esse tipo de alterações.

Bom dia O erro não foi causado por um caractere especial (do tipo & ou º), como praticamente todos os sites ou fóruns vão assinalar. Era que o certificado digital não estava igual ao XML montado, como Matheus assinalou. Numa primeira etapa, as informações da nota fiscal são agrupadas numa classe, que será em seguida assinada. Numa próxima etapa, esses dados assinados serão convertidos numa variável string, que será mandada ao SEFAZ para validação. O erro foi ter feito algumas modificações na variável string logo antes do envio para o SEFAZ. O que resultava na mensagem "297 Rejeicao: Assinatura difere do calculado", pois a variável string obviamente não correspondia mais ao valor original assinado. A modificação tinha que ser feita na primeira etapa, antes da assinatura. Essa modificação era devido à presença de um campo string de nome cEAN vazio. Como o SEFAZ não reconhece um campo cEAN vazio, devia apenas colocar uma frase do tipo "campo cEAN vazio" no campo. Agradeço pela ajuda!

obrigado! eu vou desinstalar o acbr e reinstalar!

Bom dia. Assim que possível nosso expert @Rafael Dias verificará. Att.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Vi que foi realizado modificação, sugerida pelo Denis. Obrigada.

Bom dia Camilo, Deveria sim ser um padrão, mas infelizmente o que a ABRASF publicou não foi um manual com o padrão que todos devem seguir e sim um manual de sugestão. É por isso que a NFS-e é a zorra que é hoje. Na medida do possível impomos condições nos fontes do componente para que o mesmo consiga contornar essas situações. A principio temos que utilizar a técnica TE - Tentativa e Erro.

Tente compartilhar ela no servidor e utilizar via rede \\Servidor\Impressora

Um beijo pra você meu amigo. Vou corrigir dentro do meu programa. Obrigado

Tópico repetido. Por favor, acompanhe pelo tópico abaixo.

https://www.projetoacbr.com.br/acbr-mapas-fiscais/

Verifique esse link por favor

Aqui mesmo no fórum há um vídeo explicando a instalação do ACBr Home -> Videos -> Vídeos Abertos -> Vídeos Aulas -> Como instalar o ACBr

Não os clientes vinculados com o outro certificado continuaram funcionando. Os que já estão funcionando não precisa mudar nada, agora os novos precisaram ser cadastrado como se fosse da outra empresa. Para mais informações acesse a pagina abaixo https://portal.fazenda.sp.gov.br/servicos/sat/Paginas/perguntas-frequentes.aspx

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Boa Noite, problema resolvido.... tudo funcionando bem em vários logins

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

desculpa esqueci de retirar as aspas da UF, agora esta funcionando perfeitamente bem obrigado pela ajuda,

Para tratar erros referente a itens da NFC-e em contingência, eu carrego ela, limpo os itens e adiciono novamente com os erros corrigidos.

Provavelmente é permissão, pois você deu premissão para o root e não para os outros usuários. Recomendo criar um grupo de usuários e dar permissão para este grupo e colocar todos os usuários nele.

Olá pessoal, Foi publicado agora em dezembro/2019 um novo manual de especificação técnica do DANFE da NFC-e, trata-se da versão 5.1 desse manual. O que temos de novidade: 1. algumas correções que deixa mais claro o que pode e o que não pode ser impresso. 2. traz nessas correções as novas tags cMsg e xMsg que poderão estar presentes juntamente com as demais informações referente ao protocolo de autorização gerado pela SEFAZ-Autorizadora e o local correto da sua impressão. 3. apresenta o local correto de imprimir os valores de vFrete, vSeg, vDesc e vOutro que a critério da UF poderão estar discriminados por Itens. A versão 5.1 do Manual de Especificações Técnicas do DANFE da NFC-e se encontra em nossa biblioteca. Convido a todos a lerem. Observação: Os componentes para impressão do DANFE da NFC-e feitos em Fortes Report e EscPos já estão em conformidade com a versão 5.1 do manual, portanto procurem manter os fontes sempre atualizados.

RESOLVIDO! Removido o kaspersky e voltou ao normal. Deve haver alguma configuração que permita trabalhar com ele mas foi mais rápido desinstalá-lo por completo.

Boa tarde Srs... A titulo de conhecimento: 20/12/2019 - ATENÇÃO: SVRS - Desativação dos protocolos SSL, TLS 1.0 e TLS 1.1. A Sefaz Virtual do Rio Grande do Sul (SVRS), para garantir o bom funcionamento do Ambiente de Autorização dos Documentos Fiscais Eletrônicos, deverá desabilitar os protocolos de comunicação mais antigos a partir do dia 16/01/2020. Esta mudança é necessária, não só pela simplificação do ambiente e aumento da segurança, como também pela inviabilidade de configuração dos protocolos de comunicação mais antigos em nova versão do sistema operacional dos servidores. Período de desativação: - Protocolos SSL e TLS 1.1: entre os dias 16 e 21/01/2020. - Protocolo TLS 1.0: entre os dias 21 e 30/01/2020. A partir do dia 30/01/2020, o Ambiente de Autorização dos DF-e deverá suportar unicamente o protocolo de comunicação TLS 1.2, conforme previsto na documentação técnica, vide NT 2016.002 da NF-e e NT 2017.002 do CT-e. fonte: http://www.cte.fazenda.gov.br/portal/informe.aspx?#87

So pra manter o pessoal a par o assunto, entramos em contato com a EPSON e o técnico fez uma alteração no driver e nos enviou para testes. iremos testar no cliente e aviso aqui.

Boa tarde Pessoal, Os documentos: CT-e - Conhecimento de Transporte Eletrônico e CT-e OS - Conhecimento de Transporte Eletrônico Outros Serviços, possuem um evento chamado: Prestação do Serviço em Desacordo. O autor desse evento, ou seja, que envia ele para a SEFAZ é o tomador do serviço. Esse evento, permite ao tomador informar ao Fisco que o CT-e/CT-e OS que o relaciona esta em desacordo com a prestação do serviço. O tomador tem um prazo máximo de 45 dias a contar da data de autorização do CT-e/CT-e OS para enviar o evento. Detalhe importante: O evento tem que ser enviado para a SEFAZ do emitente do CT-e, supondo que o emitente seja de São Paulo devemos: 1. Configurar o componente para a UF do Emitente (Configuracoes.webservices.UF := 'XX'; // onde XX é a UF do Emitente do CT-e) 2. Ao alimentar o componente informar em cOrgao a UF do Emitente do CT-e. Como montar a rotina para enviar o evento: ACBrCTe1.EventoCTe.Evento.Clear; with ACBrCTe1.EventoCTe.Evento.Add do begin infEvento.nSeqEvento := 1; // Para o Evento de Prestação do Serviço em Desacordo nSeqEvento sempre = 1 InfEvento.cOrgao := UFtoCUF(xUF); // Devemos informar a UF do Emitente do CT-e infEvento.chCTe := Copy(ACBrCTe1.Conhecimentos.Items[0].CTe.infCTe.Id, 4, 44); infEvento.CNPJ := xCNPJ; // CNPJ do Tomador infEvento.dhEvento := now; infEvento.tpEvento := tePrestDesacordo; infEvento.detEvento.xObs := trim(sOBS); // minimo 15, máximo 255 caracteres end; iLote := 1; // Numero do Lote do Evento ACBrCTe1.EnviarEvento(iLote); No exemplo acima o XML do CT-e/CT-e OS foi carregado, mas não se faz necessário, caso não deseja carregar o XML basta informar a chave (44 dígitos) ao campo chCTe. No campo xObs deve constar uma observação do tomador que justifique o desacordo do serviço prestado. Em caso de dúvidas, clique aqui para criar um novo tópico.