Painel de líderes
Conteúdo popular
Showing content with the highest reputation on 30-12-2019 em todas as áreas
-
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.5 pontos
-
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.4 pontos
-
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.3 pontos
-
3 pontos
-
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.asp2 pontos
-
Bom dia Muito obrigado pela alteração @Italo Jurisato Junior2 pontos
-
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.2 pontos
-
O responsável pela compilação é o nosso servidor de build eu vou ver com o @Daniel Simoes o que pode estar ocorrendo2 pontos
-
Bom dia Fernando, Muito obrigado pela colaboração, já foi enviando para o repositório.2 pontos
-
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 uso2 pontos
-
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 TabServicos2 pontos
-
2 pontos
-
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.2 pontos
-
Boa tarde! Estava realizando alguns testes na União de Arquivos SPED ECF, e notei que no arquivo não estava sendo gerado alguns registros, sendo necessário realizar as alterações citadas nas classes abaixo: * unit ACBrEFDBloco_C_Importar -> Atribuído valores nas variáveis "NUM_TANQUE" e "QTDE", na procedure "TACBrSpedFiscalImportar_BlocoC.RegC171". * unit ACBrEFDBloco_H_Importar -> Criado a procedure "RegH990", onde é atribuído valor à variável "QTD_LIN_H", e será chamada na procedure "AnalisaRegistro". * unit ACBrEFDBloco_1_Importar -> Criado as seguintes procedures: "Reg1300", "Reg1310", "Reg1320", "Reg1350", "Reg1360", "Reg1370", que serão chamadas na procedure "AnalisaRegistro". ACBrEFDBloco_H_Importar.pas ACBrEFDBloco_1_Importar.pas ACBrEFDBloco_C_Importar.pas1 ponto
-
Perfeito, funcionou. Tinha que setar lá no cedente. Muito obrigado. DEUS o abençoe. Feliz ano novo a todos.1 ponto
-
Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.1 ponto
-
Boa tarde, Italo. Ajudou sim. Deu certo. Muito obrigado.1 ponto
-
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.1 ponto
-
Voce está abrindo outro video... Apenas clique no botão "Ver Agora" Link direto1 ponto
-
Bom dia Natan, Já enviei a sua alteração para o repositório, muito obrigado pela colaboração.1 ponto
-
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.1 ponto
-
Bom dia pessoal O município de Guaíba / RS mudou o provedor de Ginfes para IPM. Mudança no arquivo Cidades.ini: De: Nome=Guaiba UF=RS Provedor=GINFES NomeURL_H=guaiba NomeURL_P=visualizar LinkURL_H=nfs_guaiba LinkURL_P=nfs_ver4 Para: [4309308] Nome=Guaiba UF=RS Provedor=IPM1 ponto
-
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.1 ponto
-
Não vai funciona com StdCall mesmo a classe é feita para consumir a dll em Cdecl, sobre este erro ai não consegui simular o mesmo aqui, tem um passo a passo de como fazer ele usando o demo ? E eu to vendo pelo log que você toda hora esta chamando o inicializar da lib, pode ser isso que esta ocasionando o erro ele precisa ser chamado apenas uma vez e quando parar de usar deve se chamar o metodo finalizar.1 ponto
-
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!1 ponto
-
Obrigado, deu certo fazer a instalação no Delphi 7. Tem algum projeto para Delphi 7 para indicar para emitir NFe como exemplo ? Att1 ponto
-
1 ponto
-
Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.1 ponto
-
1 ponto
-
Vi que foi realizado modificação, sugerida pelo Denis. Obrigada.1 ponto
-
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.1 ponto
-
Bom dia Guilherme, Com essa informação de sempre gerar a tag da Alíquota quanto se tratar de contribuinte do Simples Nacional, podemos incluir uma condição para essa tag.1 ponto
-
Bom dia Rafaela, Por favor vamos seguir as regras do fórum, essa postagem é a terceira que eu encontro sobre o seu problema. Como você é usuário do SAC procure sempre postar na área destinada aos usuários do SAC e aguarde por uma resposta dos consultores e moderadores. Outra coisa o assunto que esta sendo tratado nesse tópico não tem nada haver com o seu problema. Obrigado pela compreensão.1 ponto
-
Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.1 ponto
-
Tente compartilhar ela no servidor e utilizar via rede \\Servidor\Impressora1 ponto
-
1 ponto
-
1 ponto
-
1 ponto
-
1 ponto
-
1 ponto
-
desculpa esqueci de retirar as aspas da UF, agora esta funcionando perfeitamente bem obrigado pela ajuda,1 ponto
-
1 ponto
-
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.1 ponto
-
Boa tarde Edivan, Nesses clientes cuja conexão é ruim, na segunda vez que você tenta enviar esta lendo do banco de dados o valor gerado para cNF ou esta atribuindo o valor zero ao respectivo campo? O correto é usar a função GerarCodigoDFe, salvar no banco de dados o código gerado e ao alimentar o componente com os dados da venda atribuir o código que foi salvo no banco de dados. Lembre-se que esse código deve ser gerado e salvo no banco de dados para cada nota emitida. Provavelmente você tem uma tabela no banco de dados onde cada registro representa uma nota, correto? Pois bem, nessa tabela se faz necessário termos um campo para guardar o código gerado e que ao alimentar o componente deve ser atribuído ao campo cNF. Espero ter ajudado.1 ponto
-
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.1 ponto
-
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.1 ponto
-
Se consta na consulta no portal e não consta no XML provavelmente o seu XML está errado.1 ponto
-
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.1 ponto
-
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?#871 ponto
-
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.1 ponto
