Painel de líderes

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.

Verdade @Italo Giurizzato Junior, que confusão que fiz... Que viagem estratosférica a minha . Na minha cabeça estava achando que era uma configuração do webservice... Sabe a expressão "como não vi isso antes?" kkk. Peço desculpas e obrigado. Vou pegar o serviço correto, continuar os testes e quando estiver ok, envio os dados/arquivo da cidade para adicionar no SVN.

Boa tarde @sortee_vinicius tudo joia? A informação de rastreabilidade entendo que não depende de ser documento referenciado/coberto. Na NT 2016.002 não tem essa especificação, então acredito sim que deva constar também no documento que referencia o cupom.

Boa tarde Juliomar... Eu ia fazer o procedimento solicitado pelo @Daniel InfoCotidiano, mas o cliente colocou o sistema em outro computador e acabei priorizando outras pendências. Assim que tiver um tempo pretendo fazer esse procedimento, mas fora isso não tenho nenhuma outra idéia. Meu Delphi é o 11.

Boa tarde Willian, Assim que você tiver a certeza que o provedor é IPM e qual a versão e URLs definidas para a cidade em questão, você mesmo pode incluir ela no arquivo ACBrNFSeXServicos.ini e realizar os testes. Como fazer a inclusão leia esse tópico:

Foi criada a #TK-3291 para análise mais aprofundada do problema e parecer dos consultores responsáveis.

Boa tarde, Primeiramente favor anexar o arquivo ACBrNFSeXServicos.ini com a inclusão da cidade para que possamos enviar para o SVN. Segundo é bem provável que você esteja enviando um RPS com o ItemListaServico não disponível para o prestador de serviço em questão. Você pode verificar com o contador desse prestador quais são os Itens de serviço disponíveis para ele.

@Italo Giurizzato Junioreste xml que anexei foi gerado pelo componente antigo. Com o novo compoente não estou conseguindo obter o xml, estou testando com o demo mas sem sucesso não consegui ainda em nenhuma propriedade do componente ou arquivo que gere neste formato, vou anexar aqui o manual que me disponibilizaram e um xml de exemplo de como deveria ficar o retorno. Manual_web_services_v1.8.pdf nfs_6617.xml

Boa tarde Vilmondes, Já inclui na minha lista de tarefas para analisar o problema. TK-3290

Boa tarde, No XML que você anexou não contém os dados do prestador, sendo assim você vai ter que passar esses dados através das propriedades de configuração do componente DANFSE. Quanto as demais dados, já inclui na minha lista de tarefas para analisar o problema. TK-3289

essa dúvida um contador ou uma consultoria na area pode responder acho que o marco do SAC fiscal pode ajudar @marcopoloviana

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

Boa tarde, Sim, recebi!

Descupla anexei o xml errado, considere este de agora. 41-nfse.xml

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

https://stackoverflow.com/a/58201316/3604341 Não tem como mesmo colocar um breakpoint no Break, Exit, ou Continue. O que você pode fazer é colocar um breakpoint no IF acima e definir nele a mesma condição do Break.

Bom dia, Atualizar aqui e tão logo posto retorno. Grato!

Bom dia Willian, Já inclui na minha lista de tarefas para analisar o problema. TK-3286

Analisando o cenário, percebemos que o HubDelivery está retornando o erro num formato diferente do padrão OpenDelivery, onde no OpenDelivery especifica um JSONObject como retorno de erro e o HubDelivery está retornando um JSONArray diferente do formato da especificação. Já acionamos o HubDelivery e foi aberta uma issue com eles para adequar a resposta de acordo com a especificação do OpenDelivery. Enquanto isso para conseguirmos um tratamento mais amigável, colocamos no componente um Evento OnHTTPError para que possa tratar esse tipo de erro de forma customizada e amigável. Por favor atualize os fontes e teste novamente esse cenário, o exemplo também está atualizado com esse evento. Att.

https://youtu.be/VRydAYu7tXI

Bom dia Carlos, Favor atualizar os fontes, reinstale o ACBr e faça novos testes.

Bom dia, vou providenciar os dados e enviar para o e-Mail informado.

Bom dia! Estou mandando um print com as telas de configuração do mesmo. Assim como estou mandando o ACBrMonitor.ini com as configurações dos boletos. Dentro das pastas de configuração, que foi definido no ACBrMonitorPlus não esta gerando esses arquivos, o único arquivo que foi gerado dentro da pasta remessa foi o arquivo que já foi enviado anteriormente. ACBrMonitor.ini

@suporteatinfo Bom dia ! Li que você teve rejeição no boleto, não aceita cedente no layout deles. Pode me mandar o manual/documentação fornecida por eles por favor para que possamos analisar as alterações. Grato !

Segue o log da tentativa de emissão: ACBrLibNFE-20221116.log

Estou utilizando a última versão e as classes de alto nível, vou lhe enviar o xml no privado

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

@EveCar bom dia, pode fazer um teste por favor, nos campos instruções do boleto: Instrucao1=01 Instrucao2=02

ambos vai funcionar igual diferença que se usar o arquivo pfx seja no banco guardado ou num diretorio é que não vai precisar ficar instalando e ainda podendo ter problemas com atualizações do windows

@Juliana Tamizou Realizei mais uns testes e encontrei um problema que essa alteração gerou, ao gerar a linha digitavel. Consultando a documentação do banco ficou confuso o tratamento que deve ser feito: Então por favor não fazer a alteração solicitada a cima. Pode encerrar o Tópico, assim que confirmar a situação com o banco reporto caso haja necessidade de fazer alguma alteração no componente do ACBr. Grato pela atenção e peço desculpas por qualquer transtorno.

Italo, No meu arquivo .ini a inscrição está: [3503307] ; Atualizado em 20/09/2021 Nome=Araras UF=SP Provedor=SigISSWeb ProRecepcionar=https://wsararas.sigissweb.com/ Vou testar o programa de exemplo e posto o retorno

LOG.TXT S1010.INI

Obrigado pela contribuição, em breve será validada para possível inclusão ao svn TK-3270

Em 28/09/2022 foi publicado no DOU o Ajuste SINIEF 32/2022, o qual prorroga a vigência da Nota Fiscal Avulsa e de Produtor Rural para 31/12/2023, onde após esta data, estes contribuintes DEVERÃO passar a realizar a emissão da NFe. Sobre a NFA e a NFPR A Nota Fiscal Avulsa - NFA -, e a Nota Fiscal de Produtor Rural - NFPR -, são documentos fiscais de uso das respectivas Secretarias de Fazenda, que serão emitidas pelos sistemas eletrônicos próprios das correspondentes Secretarias de Fazenda, disponíveis em seus respectivos endereços eletrônicos Ficam excluídos deste ajuste: Acre, Amapá, Pernambuco, Rio Grande do Norte e Sergipe. Fonte: https://www.confaz.fazenda.gov.br/legislacao/ajustes/2022/ajuste-sinief-32-22