Italo Giurizzato Junior

Boa tarde Jefferson, Muito obrigado pela contribuição, já inclui na minha lista de tarefas para analisar. TK-2489

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

Boa tarde Luciane, A SEFAZ-RS ficou parada por 30 minutos hoje, não sei se foi algum problema técnico ou se essa parada se deu ao fato deles atualizarem os seus webservices com os campos novos. Favor tentar novamente, se o problema persistir, significa que a implementação dos novos campos nos WebServices estão atrasados.

Bom dia Luiz, Notei que os seus fontes estão desatualizados. Favor fazer uma cópia das Units que você alterou e atualize todos os fontes de todas as pastas e reinstale o ACBr. Por fim faça novos testes.

Bom dia a todos, @Mauricio Andrade, favor entrar em contato com o provedor e questiona-lo sobre: O XML envio da consulta não deve ser assinado, porém, o certificado digital deve ser adicionado à chamada do serviço. Não assinar o pedido de consulta isso o componente já faz. Como é que eles querem que o certificado seja adicionado a chamada do serviço? Precisamos de um exemplo.

Bom dia Anderson, Na razão social da empresa contem o caractere "&" e para que a nota fosse autorizada foi necessário trocar pelo caractere "e", correto? Não entendi a necessidade de cancelar a nota e emitir outra correta. Caso a nota contem algum valor errado, cancele e emita outra com o valor correto.

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.