Diego Foliene

Olá pessoal! No dia 07/03/2024 foi publicado um comunicado avisando com antecedência sobre a atualização da URL do QrCode presente na NFCe para o estado da Paraíba. Atualmente, a URL nova e antiga estão coexistindo, mas a partir do dia 01/04/2024, somente a URL nova (http://www.sefaz.pb.gov.br/nfce) será considerada. O comunicado informa ainda que um terço das NFCe emitidas ainda estão utilizando a URL antiga. As soluções ACBr já fazem uso da nova URL conforme pode ser visto em ACBrNFeServicos.ini: [NFCe_PB_P] Usar=NFCe_SVRS_P URL-QRCode=http://www.sefaz.pb.gov.br/nfce ;... [NFCe_PB_H] Usar=NFCe_SVRS_H URL-QRCode=http://www.sefaz.pb.gov.br/nfcehom ;... Leia o comunicado na íntegra AQUI. Um agradecimento ao membro de nossa comunidade @Fernando Di Pace por compartilhar a informação em nosso Discord.

Obrigado pela análise. Foi criada a #TK-5185 para análise do caso e parecer por parte da equipe de consultores.

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

Olá pessoal! No dia 07/03/2024 foi publicado o Informe Técnico 2024/001 que divulga atualização na tabela de NCM a partir de 01/04/2024, 01/07/2024 e 01/08/2024. Este informe trás as seguintes alterações na Tabela de NCM divulgada na NT2016/001 - v3.70: O término da vigência do código NCM 02071400 foi alterado para 31/07/2024. O início da vigência dos códigos NCM 02071411, 02071412, 02071413, 02071419, 02071421, 02071422, 02071423, 02071424, 02071429, 02071431, 02071432, 02071433, 02071434 e 02071439 foi alterado para: 01/08/2024. Extingue o código NCM 85045000 a partir de: 30/06/2024. Inclui os códigos de NCM 48119020, 85045010 e 85045090 a partir de: 01/07/2024. As demais alterações impostas na versão 3.70 continuam mantidas, sendo elas: Extinção dos códigos de NCM 27109100, 28201000, 28273998, 29299021, 29299022, 29299029, 29314930, 29398000, 30024993, 39072990, 39172200, 48119010, 74094010, 85059010, 85441910 e 90029000 a partir de: 31/03/2024. Inclusão dos códigos de NCM 27109110, 27109120, 27919190, 28201010, 28201090, 28273931, 28273939, 28439040, 29299031, 29299039, 29299040, 29299050, 29299060, 29314931, 29314932, 29314939, 29315995, 29315996, 29315998, 29333936, 29333941, 29333942, 29398010, 29398090, 38249961, 38249962, 38249969, 39072991, 39072999, 39172210, 39172290, 48119011, 48119019,74094011, 74094019,84502020, 85043193, 85059011, 85059019, 85441911, 85441919, 90029010 e 90029090 a partir de: 01/04/2024. A partir de agora, as alterações de NCM serão divulgadas por meio de Informe Técnico e não mais Nota Técnica. Leia o Informe na íntegra AQUI. Um agradecimento ao membro de nossa comunidade @Rafael - ATS Informática por compartilhar a informação em nosso Discord.

Olá pessoal! Foi publicado na página Sobre o SAT aviso informando que no dia 08/03/2024, no período das 14h00 até às 16h00 haverá uma manutenção emergencial que poderá afetar as ativações de equipamentos SAT. A Sefaz indica que ativações de novos equipamentos sejam feitas fora deste período. Um agradecimento ao membro de nossa comunidade @marcopoloviana por compartilhar a informação em nosso Discord.

Por favor, como você fez a chamada no método? O log demonstra que não foram passados para ele os parâmetros correspondentes. O comando PIXCD_GerarQRCodeEstatico tem a estrutura: PIXCD_GerarQRCodeEstatico(Valor, InformacoesAdicionais, TxId);

Bom dia! De fato são propriedades diferentes. Vamos verificar esta questão. Por enquanto, tente fazer dessa forma, definindo o escopo: case ACBrBPe1.Configuracoes.WebServices.Ambiente of TpcnTipoAmbiente.taProducao: Ide.tpAmb := TACBrTipoAmbiente.taProducao; TpcnTipoAmbiente.taHomologacao: Ide.tpAmb := TACBrTipoAmbiente.taHomologacao; end;

Bom dia! A documentação foi atualizada com estes novos exemplos visando tornar mais enxuto o preenchimento do INI removendo campos que possam causar confusão na hora de realizar o preenchimento. Se você conferir, o Modelo NFSe.INI - Provedores Layout ABRASF é baseado no Modelo NFSeINI-Um Servico, enquanto que o Modelo NFSe.INI - Provedores Layout Proprio é baseado no ModeloNFSe.INI - Mais de um Servico. Por favor, quais informações você sentiu falta nestes novos modelos?

Boa tarde! Foi criada a #TK-5180 para análise do caso e parecer da equipe de consultores.

Olá pessoal! No dia 06/03/2024 foi divulgada a versão 1.50 da Nota Técnica 2020/001. A nova versão visa atender ao que foi disposto no Ajuste Sinief 43/23, mais especificamente o § 2º da cláusula décima quinta-C. Permitindo agora que os eventos de manifestação conclusivos, sejam eles Confirmação da Operação, Desconhecimento da Operação ou Operação Não Realizada possam ser registrados até duas vezes, sendo válido apenas o último registro. Então agora, conforme exemplo dado na própria NT, o destinatário pode confirmar uma operação, depois desconhecê-la e por fim confirmá-la novamente. É importante reforçar que o envio desses eventos devem ocorrer dentro do prazo de 180 dias a partir da data de emissão da NFe. A regra de validação da rejeição 594 foi alterada e passa a vigorar com a seguinte redação: Previsão de Implementação por parte da Sefaz Implantação Teste: 01/07/2024 Implantação Produção: 01/08/2024 Para quem utiliza as soluções ACBr, não precisa se preocupar com alterações, visto que é alteração do lado da SEFAZ/AN 91. Porem um ponto de atenção : Sistemas de monitoramento podem gerar conflitos de eventos, visto que o documento foi confirmado, depois houve o registro de operação não realizada pelo operador do sistema, caso algum sistema passar registrando o evento automático, por exemplo sistema de busca de XML e registrar novamente o evento de confirmação da operação, agora a SEFAZ irá acatar o evento novamente, não retornando duplicidade de registro de evento. E a validade é do ultimo evento conclusivo registrado. Então é importante que verifiquem se não há ferramenta que possa estar consultando em concorrência realizando a manifestação automaticamente antes da consulta. Leia a NT na íntegra AQUI.

As soluções ACBr para emissão de Nota Fiscal de Serviço Eletrônica abstraem ao máximo as diferenças entre as implementações dos diversos provedores. Mesmo fazendo isso, alguns padrões precisam ser determinados. Por exemplo, a solução espera enviar e receber um arquivo no formato XML. Mas existem provedores por exemplo que devolvem simplesmente. <?xml version="1.0" encoding="UTF-8"?>You do not have permission to view this directory or page. Vejam que isso não é um arquivo XML válido. Em casos como esse a solução tenta ler o retorno esperando um XML válido, encontra isso e devolve o erro: Mas então o que eu posso fazer neste caso? A primeira coisa a se fazer ao receber este erro é conferir qual é o conteúdo do arquivo de retorno, pois é alta probabilidade de que o mesmo tenha um conteúdo em formato inválido ou erro não previsto. O mais indicado é que se confira no arquivo -soap, que é o retorno completo devolvido pelo web service. No tópico abaixo tem orientações de como configurar para que seja gerado estes arquivos: Conferindo nesses arquivos, fica mais fácil para você e também para a equipe ACBr entender qual foi o erro e determinar qual é o curso de ação a ser tomado.

A versão 1.01 do IPM requer que seja enviado no header da requisição um elemento Authorization que consiste no BASE64 do usuário e senha usados para emissão. Vide manual que disponibilizou. Você precisa preencher no componente as propriedades ACBrNFSeX.Configuracoes.Geral.Emitente.WSUser e ACBrNFSeX.Configuracoes.Geral.Emitente.WSSenha.

Por favor, qual é a configuração de TimeOut que está utilizando? As informações de autenticação foram preenchidas corretamente no componente?

Bom dia! Alteração enviada ao SVN na Rev-32808. Por favor, queira atualizar seus fontes e reinstalar o ACBr para realizar novos testes.

Tópico movido para a área do SAC, para que o SLA de respostas seja considerado

Bom dia! Apenas para desencargo, por favor, tente efetuar um teste usando o método de consulta manualmente após usar o método de envio e veja se ele lhe devolve todas as informações.

Temos um exemplo em Node.js em nosso SVN. Por favor, pode realizar um teste com o mesmo?