Italo Giurizzato Junior

Boa tarde Gustavo, Já inclui na minha lista de tarefas. TK-3420

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

Olá Pessoal, O ENCAT publicou uma nova versão da NT 2022/003 (versão 1.10), e já de inicio destacamos que os prazos permanecem os mesmos da versão 1.00 da NT, ou seja 07/02/2023 para homologação e 03/04/2023 para produção. Vamos as mudanças desta versão da NT... Novas Regras de Validação Regras de Validação relativas as tags refNFE e refNFeSig (BA02-60 e BA02a-110 ) Estas regras visam garantir que quando houver uma Chave referenciada (tag: refNFe) ou uma Chave Referenciada com código numérico zerado (tag: refNFeSig), o tipo de emissão da chave referenciada seja válido. Regra validando o conteúdo da tag refNFeSig (BA02a-74) Esta regra visa garantir que, quando houver uma Chave Referenciada com código numérico zerado (tag: refNFeSig), o código numérico seja efetivamente zerado. Regra validando a informação de valor na tag refNFeSig quanto a adesão da UF (BA02a-120) Esta regra visa evitar que seja utilizado o campo de Nota Referenciada com código numérico zerado (tag: refNFeSig) em UF que não permite tal referência. Ajustes em regras existentes Ajuste na definição de quais modelos de DFe a regra se aplica (BA02a-90) A coluna de modelo desta regra havia sido deixada em branco equivocadamente, alterada para constar sua aplicabilidade somente para o modelo 55. Alteração da descrição quanto a aplicabilidade da regra, que no momento é somente para o CE (N17c-30) Alterada a descrição da RV N17c-30 para que fique claro que ela somente se aplica, neste momento, para o Ceará. O Estado do Ceará realiza o controle do FCP de forma diferente das demais UF, o que acarreta na necessidade de implementação desta regra. Exclusão de regra incluída na versão 1.0 Exclusão da Regra para validação de informação de Cupom Fiscal como Doc Referenciado (I08-186) Esta regra foi removida pois a UF que assim desejar pode bloquear Cupom Fiscal referenciado através da ativação da Regra BA20-30 (NT 2019.001). Como a Regra I08-196 sequer chegou a ser implementada, o código de Rejeição inicialmente alocado a ela foi reaproveitado nesta mesma NT. Novas Regras de Validação com Implementação Futura Regras de validação quanto ao modelo de documento referenciado (BA02-70 e BA02-80) Estas regras visam evitar que sejam referenciados documentos eletrônicos diferentes do modelo 55 em devoluções internas de mercadoria e também em devoluções envolvendo consumidor final. Regras com implementação futura.

Boa tarde Alex, Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-3416

Bom dia Fabio, Você poderia anexar o XML da NFS-e para que possamos analisar?

Boa tarde Márcio, Os campos: ProLinkURL e HomLinkURL que constam no arquivo ACBrNFSeXServicos.ini são utilizado pelo método LinkNFSe para gerar uma URL para ser enviada para o tomador de serviço, para que este possa imprimir o DANFSE e em alguns casos baixar o XML da nota. Pelo que me recordo se no tag Discriminacao do XML da NFS-e contem uma URL esta é usada para gerar um QR-Code ou quando é gerado o tag Link.

Boa tarde, Os arquivos temp1 e temp2 são arquivos gerados pelo programa exemplo para fins de estudo, sendo assim a sua aplicação não deve gerar esses arquivos.

Boa tarde Raphael, Muito obrigado pela contribuição, já inclui na minha lista de tarefas. TK-3415

Boa tarde, Se tratando de provedores que seguem o layout da ABRASF o campo OutrasInformacoes pertence ao layout da NFS-e e não ao do Rps que devemos gerar e enviar para o provedor. Logo quem gera o conteúdo para o campo OutrosInformacoes é o próprio provedor ao gerar o XML da NFS-e. Com relação a diferença entre os campos Discriminacao e Descricao é que no provedor CTAConsult temos a tag <descricaoServico> que é gerada com o conteúdo do campo Discriminacao e a tag <descricaoAtividade> que é gerada com o conteúdo do campo Descricao.

Boa tarde Jhonlenon, Se tratando de Documentos Auxiliares como o caso do DACTE é importante informar se o que você usa é o DACTE feito em Fast ou Fortes Report. Segundo, acredito que para imprimir essa informação o componente pegou da chave. Sendo assim qual é a série que consta na chave?

Olá Pessoal, A NT 2022.005 se refere ao DIFAL, ou seja a questão do ICMS nas Operações Interestaduais de Venda ao Consumidor Final, relativa a Regra de Validação NA01-200, que obriga a informação do grupo do ICMS devido para a UF de destino (grupo “ICMSUFDest”), que havia sido suspensa no início de 2022. Esta NT também insere regras de validação relativas a devolução, englobando as questões relacionadas as operações deste tipo. Oque exatamente diz a legislação... Deverá ser considerado como destino, a UF de Entrega da mercadoria ou o fim da prestação de serviços, conforme citado no trecho da legislação transcrito abaixo. “§ 30 Nas operações e prestações interestaduais destinadas a consumidor final não contribuinte, para fins do disposto neste convênio, quando o destino final da mercadoria, bem ou serviço ocorrer em unidade federada diferente daquela em que estiver domiciliado ou estabelecido o adquirente ou o tomador, considerar-se-á unidade federada de destino aquela onde ocorrer efetivamente a entrada física da mercadoria ou bem ou o fim da prestação do serviço.” Sobre as novas Regras de Validação Nesta mesma Nota Técnica, foram incluídas Regras de Validação para controlar a NF-e de Devolução. Esse tipo de NF-e obriga a informação da(s) NF-e referenciada(s). Nesta NT são incluídas validações para verificar se o Valor Total da NF-e de Devolução é maior do que o Valor Total das NF-e citadas como devolvidas (NF-e referenciadas). Sobre a entrada em vigor Homologação: 07/02/2023 Produção: 06/04/2023 Mudanças necessárias na aplicação Por tratar-se de regras de validação de tags já existentes, pode caber neste momento uma revisão se a aplicação esta enviando corretamente as informações. Além disto nenhum ajuste nas soluções ACBr se faz necessário Link para o portal da SEFAZ onde estão listadas as NTs http://www.nfe.fazenda.gov.br/portal/listaConteudo.aspx?tipoConteudo=04BIflQt1aY=

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

Olá Pessoal, O ano não poderia terminar sem termos novas Notas Técnicas saindo, não é mesmo? Mas desta vez trata-se de algo com pouco ou nenhum impacto nas aplicações, uma vez que trata-se apenas de aperfeiçoamento da regra de validação especifica a existência de serviços na NFe/NFCe, algo que sempre foi bastante restrito de forma geral. Detalhando melhor... Essa NT tem o objetivo de aperfeiçoar a regra de validação do campo de ISSQN, permitindo que as UF possam parametrizar com precisão a aceitação, ou não, da autorização de NF-e/NFC-e com a Tag de item de Serviço. Essa NT vem da necessidade de o Distrito Federal adequar a emissão das notas fiscais eletrônicas, modelo 55 e 65, dos seus contribuintes em virtude da publicação de legislação interna para implementação da NFSe a qual temos falando a algum tempo. Sobre os Prazos para Implantação Homologação: até 28/12/2022 Produção: 02/01/2023 - Conforme, calendário de cada UF Observação: no meu entendimento essa data informada em produção deve ser a partir de 02/01/2023, mas cada UF vai implantar na data que melhor convêm. Oque muda nas soluções ACBr e/ou na aplicação Absolutamente nada, uma vez que trata-se apenas de uma melhora na regra e seu retorno

Bom dia Rafael, O erro 400 não tem nada haver com a tag. Favor atualizar todos os fontes de todas as pastas, reinstale o ACBr e compila a aplicação com a opção Build.

Soiivan, Configura o componente para o ambiente de produção e envia um Rps no valor de 1 real e depois cancela ele.

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

Bom dia Solivan, O ambiente de homologação do provedor Fiorilli é bugado. Favor fazer "testes" no ambiente de produção.

Boa tarde, Complementando o que todos já lhe recomendaram, vai mais uma recomendação. Peça aos seus clientes que abrem um protocolo de reclamação na prefeitura, desta forma em vez de só você reclamar, todos os seus clientes vão reclamar, desta forma a pressão é maior. Se esses caras não tomar vergonha na cara e fazer algo decente é capaz de perder a licitação e chamarem o segundo colocado.

Boa tarde, Primeiramente muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-3399 Segundo, esse arquivo é gerado pelo componente ACBrIBGE que esta sendo utilizado pelo componente ACBrNFSeX para obter a descrição do nome da cidade com base em seu código IBGE. Quanto a definir um path para salvar esse arquivo vai ser necessário analisar o código do componente ACBrIBGE para saber se existe alguma propriedade que nos permite definir um path.

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

Boa tarde, Entre em contato com o provedor, eles vão lhe mostrar onde no site da prefeitura você tem que acessar para configurar como deseja obter o retorno. Dependendo dessa configuração o webservice do provedor IPM retorna sim o XML completo da NFS-e.

Bom dia, Não entendi muito bem, os caras estão exigindo que você cadastre previamente o prestador ou o tomador de serviço? Neste caso: "Piorando o cenário, só o cartório da Asa Norte, emite-se cerca de 1500 a 2000 NFC-e por dia, sendo 98% para CPF (5% pede identificação) e os 2% para CNPJ (quando pede identificação). ", vejo apenas um prestador. Ter um cadastro prévio do prestador eu concordo, pois é ele que vai emitir as notas, agora cadastrar todos os tomadores, isso para mim deveria ocorrer de forma automática na media que você emiti as notas.

Bom dia Ricardo, Checando o código da função StrToBool notei que ela espera pela string "False" ou "True" para converter nos valores False ou True. A função NormatizarBoolean tem como objetivo retornar sempre as string "False" ou "True". Note que no XML o valor da tag Sucesso é "false", a função NormatizarBoolean recebe essa string e altera para "False" e por fim a função StrToBool retorna o valor False. Verifica se ao compilar a sua aplicação o Delphi não esta pegando uma cópia da unit ACBrXmlBase ou a sua BPL desatualizada.