Italo Giurizzato Junior

Bom dia, Alguns provedores ao gerar o XML de retorno em vez de gerar as tag com os caracteres "<" e ">" geram com a sequencia "&lt;" e "&gt;". A rotina responsável por ler o conteúdo da tag espera encontrar algo do tipo <nomeTag> e não &lt;nomeTag&gt; Com isso ele não consegue ler o conteúdo. Para resolver o problema se faz necessário realizar a troca.

Boa tarde, Por favor atualiza novamente os fontes, reinstale o ACBr, compila a aplicação e faça novos testes.

Boa tarde Maurício, O certificado deve ser adicionado a chamada do serviço? Coisa estranha, como será que eles querem que seja feita isso?

Boa tarde Lucio, Fiz um teste assinando o pedido de consulta, a rejeição mudou para: <Codigo>E160</Codigo> <Correcao>Consulte o Manual da NFS-e para saber quais são as versões de XML Schema suportadas pelo sistema.</Correcao> <Mensagem>Arquivo em desacordo com o XML Schema.</Mensagem> Se não assina, diz que esta faltando o certificado, se assina diz que o XML esta em desacordo com o schema. Favor entrar em contato com o provedor e relate o problema.

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

Boa tarde Jefferson, Sem realizar nenhuma alteração no componente, estou conseguindo enviar para o webservice do provedor. Veja: Método Executado: Enviar Lote Parâmetros de Envio Numero do Lote: 1 Parâmetros de Retorno Data de Envio : 30/12/1899 Numero do Prot: Numero da Nota: Link : Código Verif. : Sucesso : False Erro(s): Código : Mensagem: Erro: Usuario Inválido Correção: --------- Estou usando a configuração abaixo: SSLType = LT_TLSv1_2

Boa tarde, Favor atualizar os fontes e faça novos testes.

Luiz, Já esta no SVN.

Boa tarde, Qual é a estrutura de pastas que você montou para conter os schemas? Qual é o caminho que você passou para o componente?

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

Boa tarde Anadilson, Favor atualizar os fontes e faça novos testes.

Boa tarde Gabriel, Após atualizar os fontes você reinstalou o ACBr e recompilou a aplicação?

Boa tarde Tiago, Favor atualizar os fontes e faça novos testes.

Boa tarde Marcelo, Favor atualizar os fontes e faça novos testes.

Boa tarde Roseno, Me parece que esse provedor esta gerando a data em formato fora do padrão que é AAAA-MM-DD no ambiente de homologação. Já no ambiente de produção me parece que esta gerando no formato correto. Favor entrar em contato com o provedor e expor o problema. Quem sabe eles corrijam a formatação das datas nos XML de retorno gerado no ambiente de homologação.

Bom dia Elaine, O contratante é a pessoa que esta informada no MDF-e no grupo <infContratante> Note que esse grupo é uma lista, ou seja, podemos informar um ou mais contratantes, uma vez que o MDF-e pode relacionar centenas de NF-e ou CT-e com tomadores do serviço diferentes. O contratante pode ser uma pessoa física, jurídica ou estrangeiro. Eu entendo que o Contratante é o tomador do serviço. A NT não deixa claro que o evento é obrigatório ou não, mas para que o Contratante possa enviar o Evento de Confirmação do Serviço de Transporte, necessita do numero do protocolo de Autorização do MDF-e. Eu acredito que não seja obrigatório e nem um requisito para que o caminhão possa iniciar a sua viagem.

Olá Pessoal, Nas ultimas Notas Técnicas publicadas pelo ENCAT contem um item tratando sobre esse novo tipo de autorizador. O texto abaixo foi extraído de uma dessas NT. O ambiente de autorização dos documentos fiscais eletrônicos é uma parte importante do processo de faturamento das empresas e por isso demanda uma constante evolução e garantia de estabilidade, tempo de resposta e disponibilidade 24 x 7. Buscando atender essas questões, torna-se essencial que existam processos cada vez mais completos de garantia da continuidade do sistema, mesmo que existam alternativas de contingência previstas em cada DF-e. A inclusão do tipo de autorizador como identificador inicial do protocolo de resposta visa basicamente permitir que o ambiente de autorização possa disponibilizar de forma transparente para os contribuintes uma contingência dentro da sua própria governança de ativação, sem que o sistema da empresa precise ser ajustado em caso de uma manutenção ou até mesmo de um desastre no ambiente padrão da SEFAZ. Quando o Site Alternativo estiver em uso, a SEFAZ poderá estar autorizando documentos fiscais em outros datacenters físicos ou na nuvem. Para o contribuinte a diferença estará no início do número do protocolo com o dígito 2 e na própria sequência numérica do protocolo que será exclusiva desse ambiente. Alteração na Formação do Número do Recibo do Lote O número do Recibo do Lote será gerado pelo Portal da Secretaria da Fazenda, com a seguinte regra de formação: 2 posições com o Código da UF do emitente (codificação do IBGE); 1 posição com o Tipo de Autorizador (0 ou 1=SEFAZ normal, 2=Site Alternativo, 3=SEFAZ VIRTUAL-RS, 5=SEFAZ VIRTUAL-SP, 7=SVC-RS, 8=SVC-SP); 12 posições numéricas sequenciais. Alteração na Formação do Número de Protocolo O número do protocolo é gerado pelo Portal da Secretaria da Fazenda para identificar univocamente as transações realizadas de autorização de uso e registro de eventos do DFe. A regra de formação do número do protocolo é: 1 posição com o Tipo de Autorizador (1=SEFAZ normal, 2= Site Alternativo, 3=SEFAZ VIRTUAL-RS, 5=SEFAZ VIRTUAL_SP; 7 = SVC-RS; 8 = SVC-SP); 2 posições para o código da UF do IBGE; 2 posições para o ano; 10 posições numéricas sequenciais no ano.

Olá Pessoal, Foi publicado a Nota Técnica 2022/001 que trata sobre a inclusão da tag CRT - Código de Regime Tributário do Emitente. A tag foi incluída como sendo opcional, portanto os schemas já se encontram atualizados e no SVN. Já a alteração no componente só vai ser alterado na ultima semana de maio/2022, uma vez que a tag vai ser implementada no ambiente de homologação em 06/2022 e em produção 07/2022. Essa NT também trata sobre a alteração nas validações do Evento de Prestação do Serviço em Desacordo, abrindo utilização para pessoa física (CPF) com identificação pelo gov.br Ampliação do Alcance do Evento Prestação de Serviço em Desacordo Função: Evento para que o tomador possa informar ao fisco que o documento CTe que o relaciona está em desacordo com a prestação de serviço. Autor do Evento: O autor do evento é o tomador do serviço indicado no CTe. A mensagem XML do evento será assinada com o certificado digital que tenha o CNPJ base do tomador do serviço do CTe, ou o CNPJ da SEFAZ Virtual RS para tomadores pessoa física identificados por login na plataforma gov.br. Trata também sobre nova validação de CFOP. Regra G052a Para CT-e do tipo Normal, complementar ou Substituição, se UF do emitente for igual a UF de início da prestação e UF de início e fim da prestação forem diferentes de EX: CFOP não pode ser 5932 e 6932. Rejeição 831: CFOP inválido, não informar 5932 ou 6932 para operações internas

Mas o componente extrai o XML da NFS-e e o salva em disco e também esta disponível em: ACBrNFSeX1.NotasFiscais.Items[ i ].XmlNfse Para ser salvo no banco de dados.

Boa tarde Tiago, Você tem o XML da NFS-e para que eu possa analisar? Se sim, poderia anexar?

Favor atualizar os fontes e faça novos testes.

Boa tarde Marcelo, Vou conversar com o pessoal da Equipe ACBr para que juntos encontramos o problema.

Boa tarde Almeida, No motivo do cancelamento contem cedilha e vogais acentuadas? Se sim troque e vê se resolve o problema.