Painel de líderes

Boa tarde a todos, Já esta disponível em nossa biblioteca a Nota Técnica 2019/001 que trata sobre novas regras de validação. Resumo da NT: · Dificultar utilização de código de segurança fraco · Melhorar o controle de documentos referenciados e da identificação do destinatário · Descrever benefícios fiscais e informações da tributação do ICMS com mais precisão · Criação de valor máximo para a base de cálculo do ICMS, por unidade federada · Melhor gerenciamento de informações sobre o destinatário, tanto no serviço de autorização de NF-e quanto no serviço de registro de EPEC Datas previstas para entrada em vigor: 01/07/2019 - Ambiente de Homologação; 02/09/2019 - Ambiente de Produção. Alterações no componente: Nenhuma, visto que essa NT trata de novas regras de validação a serem implementadas pelas SEFAZ-Autorizadoras. Novas Regras de Validação: Criada a Regra de Validação B03-10, para dificultar a utilização de um código de segurança fraco, ou seja, o valor de cNF não vai poder ser igual ao valor de nNF e sim um numero aleatório. Criadas regras de validação a documentos referenciados:  Regra de Validação BA10-40 foi alterada, possibilitando a utilização do CNPJ 8 (somente os 8 primeiros dígitos) com o objetivo de identificar que a nota foi emitida pelo mesmo contribuinte, a critério da unidade federada. Criada a Regra de Validação BA10-50, exigindo que uma contranota de produtor rural somente possa referenciar uma nota emitida por outro produtor rural, a critério da unidade federada. Criada a Regra de Validação BA20-20, impedindo que seja referenciado um documento fiscal de uso exclusivo para operações internas em uma operação destinada a outra unidade federada ou para o exterior. Criada a Regra de Validação BA20-30, impedindo referência a um Cupom Fiscal, a critério da unidade federada. Criadas regras de identificação do destinatário: Criada a Regra de Validação E03a-30, impedindo o uso simultâneo de IE e de identificação de estrangeiro para o destinatário. Criada a Regra de Validação E14-30, impedindo informação de país de destino “Brasil” em operações destinadas ao estrangeiro. Criada a Regra de Validação E16a-40, exigindo a indicação de “operação com consumidor final” quando se indica que a operação é destinada a não contribuinte. Criadas regras de validação tornando obrigatória a informação do Motivo da Desoneração e do Valor do ICMS desonerado, caso seja informado o Código do Benefício Fiscal: Criada a Regra de Validação I05f-10, impedindo a informação de um código de benefício fiscal juntamente com um CST que não prevê benefício fiscal, a critério da unidade federada. Criada a Regra de Validação I05f-20, impedindo a informação de um código de benefício fiscal que não corresponda ao CST utilizado, a critério da unidade federada. Criada a Regra de Validação I05f-30, exigindo que seja informado o valor do ICMS desonerado ou o motivo de desoneração quando se utiliza um código de benefício fiscal, a critério da unidade federada. Criada a Regra de Validação N07-10, exigindo informações sobre o diferimento quando se utiliza um CST de diferimento, a critério da unidade federada. Criada a Regra de Validação N12-84, exigindo o código de benefício fiscal quando se utiliza um CST de benefício fiscal, a critério da unidade federada. Criada a Regra de Validação N12-88, exigindo que o CST corresponda ao tipo de código de benefício fiscal informado, a critério da unidade federada. Criada a Regra de Validação N12-90, exigindo valor do ICMS desonerado e o motivo da desoneração, a critério da unidade federada. Criada a Regra de Validação N18-10, exigindo a informação do percentual da margem de valor Adicionado do ICMS ST Informada caso a modalidade de determinação da BC da ST seja MVA, a critério da unidade federada. Criada a Regra de Validação N18-20, não permitindo informação do percentual da margem de valor Adicionado do ICMS ST Informada caso a modalidade de determinação da BC da ST não for MVA, a critério da unidade federada. Criada a Regra de Validação W03-20, impedindo a informação de um valor de Base de Cálculo superior ao valor máximo estabelecido pela respectiva SEFAZ. Emitente: Criada a Regra de Validação 1C03-10, impedindo a informação de Razão Social do emitente diferente da existente no cadastro da SEFAZ. Destinatário: Criadas as Regras de Validação 5E17-10, 5E17-20, 5E1730, 5E17-40, 5E17-43, 5E17-46, 5E17-50, 5E17-60, 5E17-63, 5E17-70 e 5E17-80, para verificar se o destinatário está sendo informado corretamente ou se está em situação que o impeça de constar na NF-e como destinatário na operação com mercadoria ou prestação de serviços.  Serviço Autorização EPEC: Criadas as Regras de Validação 6P31-10, 6P31-20, 6P31-30, 6P31-40, 6P31-43, 6P31-46, 6P31-50, 6P31-60 e 6P31-63, para verificar se o destinatário está sendo informado corretamente ou se está em situação que o impeça de constar na NF-e como destinatário na operação com mercadoria ou prestação de serviços.

Boa tarde, Conforme pôde ser observado por um grande número de membros da comunidade, desde os últimos dias de abril vinha ocorrendo na maioria das UFs a rejeição Endereço do site da UF de Consulta por chave de acesso diverge do previsto ao tentar enviar a NFCe em ambiente de homologação. Motivo da Rejeição Conforme foi divulgado posteriormente pela SEFAZ, de forma não oficial, ou seja, sem a publicação de NTs ou outras informações nos portais relativos a NFCe, esta rejeição passou a ocorrer devido a implementação da regra ZX03-20 existente na NT 2016.002 versão 1.61, a qual determina a validação da URL de Consulta por Chave de Acesso conforme tabela disponibilizada no portal do ENCAT. Estas validações entraram em vigor em ambiente de homologação no dia 22/04/2019 e em produção entrarão em 20/05/2019. Solução Os fontes do ACBr e por consequência o ACBrMonitorPlus SAC, foram atualizados com as URLs corretas conforme documentação disponível na página do ENCAT. Porém, em alguns casos, os endereços indicados pelo ENCAT ainda sim estavam incorretos. Com base no feedback de diversos usuários de nossa comunidade, novos ajustes foram enviados para o SVN do ACBr, no arquivo ACBrNFeServicos.ini Dicas para Minimizar o Impacto em seus clientes Se você utiliza o componente ACBrNFe para emissão da NFCe, procure sempre disponibilizar na mesma pasta do seu binário (executável) o arquivo ACBrNFeServicos.ini. Desta forma, o componente ACBrNFe, irá fazer uso do arquivo ACBrNFeServicos.ini existente no diretório, ao invés de usar as URLs internas, que são compiladas como "Resource", e anexadas ao componente... Isso é extremamente vantajoso, pois lhe confere grande agilidade na resolução de problemas de URLs... Caso sejam detectadas novas alterações de URLs, basta realizar a substituição do arquivo ACBrNFeServicos.ini, evitando portanto a necessidade de atualizar toda a aplicação. Eu não distribuo o ACBrNFeServicos.ini em meus instaladores? Preciso recompilar e atualizar meus clientes para que as novas URLs entrem em vigor ? Se você não quer ou não pode distribuir o ACBrNFeServicos.ini, na mesma pasta da sua aplicação, então não há outra maneira a não ser disponibilizar um novo binário para o seu cliente... Porém antes , faça um teste, é simples e rápido... Apenas copie o arquivo ACBrNFeServicos.ini no mesmo diretório de sua aplicação, e observe que as novas URLs serão utilizadas, pois o componente ACBrNFe irá priorizar o arquivo em disco. Ainda tem Dúvidas? Acesse os sub-fóruns sobre NFCe e crie um novo tópico relatando seu questionamento. Lembre-se que se for usuário do SAC Anual você também pode falar conosco pelo chat ACBr.

Bom dia. Este problema não está diretamente ligado à atualização da versão do ACBr mas sim porque a Sefaz está fazendo valer uma regra já existente a algum tempo na NT 2016.002. Essa regra começou a ser aplicada no ambiente de homologação no dia 22/04, e vai ser aplicada no ambiente de produção a partir do dia 20/05. Essa regra de validação é opcional por estado. Isso significa que cada estado pode decidir se aplica ou não essa regra de validação. Como já foi visto aqui no tópico a última compilação do ACBrMonitor PLUS já está correta de acordo com as regras, só teria que atualizar para esta última versão. Ou alterar o arquivo ACBrNFeServicos.ini com os endereços corretos.

O SCAN não é mais usado, foi desativado há tempos. Se a SEFAZ agendou a contingência o que vai ser ativado vai ser a contingência SVC. Para saber como tratar a contingência leia o manual de orientações do contribuinte, a partir da página 150: http://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=URCYvjVMIzI= No caso de SP a SEFAZ usa a SVC-AN para autorização em contingência: O que precisa fazer na aplicação: - Ajustar a configuração ACBrNFe.Configuracao.Geral.FormaEmissao := teSVCAN; - Na geração da NFe informar a tag tpEmis = teSVCAN; O restante do processo é como no envio normal, a NFe é enviada para o webservice de contingência e ele fornece o protocolo de autorização. Nada mais é preciso fazer do lado da aplicação, assim que o serviço da SEFAZ for normalizado, o próprio webservice se encarrega de sincronizar as NFe emitidas em contingência.

Favor atualizar os fontes e testar novamente.

Atualizei os fontes do ACBR, parte do SpedECF e gerei o arquivo, a princípio gerou corretamente os novos campos.

Bom dia. Os trabalhos estão avançados, em breve lançaremos esta lib. Att.

Bom dia pessoal, Pelo que vimos o erro 12002 é falha (falta ?) de comunicação com o webservice, por ele estar ou fora do ar ou sobrecarregado, não sendo portanto erro de código ou de parametrização, a única coisa que pode-se tentar fazer para contornar é aumentar o timeout. No mais é esperar pela normalização do serviço por parte da SEFAZ. Creio que o tópico possa ser encerrado. Agradeço a todos.

Obrigado @Italo Jurisato Junior... ficou um ótimo resumo

Você não deve considerar o desconto ao informar a tag vProd.

Estou homologando a unit no Banco Uniprime(84), em breve estarei divulgando aqui a unit criada, para avaliação da equipe do ACBr.

Verdade, é assim que ele faz, muito OBRIGADO MESTRE!

Você pode usar as tags de unidade de comercialização (uCom, qCom, vUnCom, cEAN) e as tags de unidade de tributação (uTrib, qTrib, vUnTrib, cEANTrib).

Enviao ao SVN. Favor atualizar, testar e reportar qualquer problema. Muito obrigado.

Depois de remover tanto a pasta inteira do ACBr quanto a do Fortes, fiz checkout novo para as duas e o problema foi resolvido.

Prezados amigos: Com base nas valiosas colaborações do Daniel (neste tópico) e do Kym (msg privada), consegui elaborar em Delphi a rotina para a assinatura digital da hash. A solução só não ficou perfeita pelo fato de eu não ter obtido sucesso em usar uma DLL Delphi no VBA, mas driblei o problema criando em Delphi a mesma rotina como um arquivo executável, que salva a assinatura digital em um arquivo txt , deixando ao VBA a simples missão de, poucos segundos depois de ter "provocado" a execução dessa rotina, ler automaticamente o txt por ela gerado em busca da desejada informação. Portanto, Questão Solucionada! Muito obrigado. EA

Boa tarde, atualizei os componentes e os enums schprocNFe, schprocEventoNFe da unit pcnConversaoNFe foram comentados, porque? E quais devo utilizar no lugar deles agora?

Bom dia a todos, Estou com uma solicitação de um cliente para homologar o banco: 84 - CC UNIPRIME NORTE DO PARANA , na lista do acbr temos apenas o cobUniprime (Codigo Febrabam 099), então tenho algumas perguntas: Existe a possibilidade de criação deste novo banco no ACBr ? Tem que ser desenvolvido por alguem da equipe do ACBr ? Ou posso desenvolver e depois enviar para avaliação da equipe ACBr ? Existe algum cuidado que devo ter ao desenvolver a estrutura para um novo banco ?

Boa Tarde! Fiz a implementação do tipo CAEPF no AcbrValidador. Se julgarem interessante segue... ACBrValidador.rar

Poxa Daniel que excelente notícia. Isso, será muito importante para nós, estamos desenvolvendo um software de gestão em java e atualmente integramos ele com o ACBRMonitorPlus, mas seria muito mais interessante termos todas as vantagem que o ACBR tem de forma nativa "Classes". Aguardaremos ansiosamente.

vlw pela resposta amigo tirou minha duvida muito obg!

As correções funcionaram, Muito obrigado.

Boa tarde. Sugiro que consulte a pasta de exemplos. Att.

Boa tarde. Por favor criei um tópico especifico para sua dúvida. Att.

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

Enviado para o repositório, rev. 16980.

Com o gerador de relatórios, como o ReportBuilder, também funciona. Valeu pela forca.

Obrigado.

O evento você programa de acordo com a sua necessidade...

Obrigado pelo retorno! Teria alguma previsão de quando seria possível?

Bom dia. Obrigada pela contribuição, adicionado para análise. Att.

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

Bom dia a todos. Sugiro que entrem em contato com a prefeitura para obter mais detalhes.

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

Me perdoe, eu pesquisei, mas pesquisei por NT 2019.001 e não encontrei. Falha minha, tem como eu finalizar esse tópico ou só um administrador? Embora, que vi agora que esse post que você mandou é uma notícia, talvez, este meu post possa servi para discutimos nossas dúvidas. Abraços

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

Não mudou, as duas opções (salvar o .ini na pasta ou recompilar o .res, acbr e aplicação) são válidas. A primeira é só mais prática para testes.

Boa tarde. Que bom que deu certo, porém seria interessante compartilhar também onde estava o problema. Att.

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

Bom dia Naiara, Me parece que houve alteração em uma das units responsáveis por realizar a assinatura no XML, favor atualizar os fontes e refaça os testes.

Também tem uma versão já compilada, disponível na área de downloads do fórum

Provavelmente foi algum erro na conversão feita pelo site. Quando fiz a conversão pelo fotoshop deu certo.

Já temos a confirmação dos Seguintes palestrantes, e que foram palestrantes da 1a Edição do Evento @Régys Silveira, @EMBarbosa @Daniel Simoes @Italo Jurisato Junior, @José M. S. Junior @Rafael Dias Edgard de Castro @Juliomar Marchetti Novos palestrantes, já confirmados: @Cantu https://firebase.com.br/

Enviado para o SVN.. Rev.16930

Não... não há um comando nativo para QRCode, implementado no ACBrETQ... Não tenho certeza se isso é suportado em PPLA/PPLB...

Por favor teste com a Unit em anexo... ela irá tentar o mesmo comando, até 5 Falhas sinalizadas com o erro 140... ACBrECFEscECF.pas

Juliomar grato pelo retorno, e sim, acontecia o mesmo, porém veja o que fiz... Quando usei o apagarACBr.bat e em seguida fiz o SVN Update para a atualização dos componentes, o arquivo ACBr.inc retornou ao seu estado original com a linha {.$DEFINE USE_MINGW}, ou seja, deixou de usar as dlls da MINGW (no meu caso) e passou a tentar a usar as dlls da \OpenSSL\0.9.8.14 .... por esse motivo começou o Acess Violation se referenciando a dll MSVCRT.DLL. Depois de identificar esse detalhe, descomentei a linha {$DEFINE USE_MINGW}, dei um Build geral por aqui e a aplicação voltou ao normal novamente não ocorrendo mais erros. De qualquer forma fica ai o caso para ajuda se algum dia alguém passar pelo problema acima. Grato.