Ir para conteúdo
  • Cadastre-se

Diego Foliene

Consultores
  • Total de ítens

    5.306
  • Registro em

  • Última visita

  • Days Won

    155

Tudo que Diego Foliene postou

  1. Bom dia @Diego Reckziegel! Apesar de não termos aceitado sua contribuição de primeira pelo motivo já exposto acima, havíamos criado uma SubTK para analisar a questão na msXML. Fizemos nova análise, novos testes e chegamos a conclusão que de fato a alteração precisaria ser feita nos fontes do ACBrNFSeX para definir o NameSpaceURI corretamente. Sua contribuição resolvia apenas para esse provedor, mas foi a base para criarmos função na classe base para resolver o problema para todos os provedores. A alteração foi enviada ao SVN na Rev-29225. Mais uma vez, muito obrigado pela contribuição. Caso queria testar com a msXML, basta atualizar e reinstalar o ACBr.
  2. Bom dia. De fato, e-mail recebido. Conforme citei anteriormente, foi detectado divergência entre a forma que é alimentada a informação nos relatórios. O time de consultores está analisando qual é a melhor forma de resolver esse questão de forma a sanar este e outros possíveis problemas semelhantes que possam vir a ocorrer. Qualquer novidade você será notificado neste tópico.
  3. Bom dia! Muito obrigado por reportar e também pela sugestão de melhoria. Foi criada a #TK-3864 para análise do caso e parecer do time ACBr.
  4. Bom dia. Neste caso, você pode se basear em outra cidade que use o mesmo provedor e seguir as orientações deste tópico aqui: Para poder testar com o programa exemplo.
  5. Boa tarde. Muito obrigado por reportar. Por favor, apenas para confirmar, pelo seu print, você está utilizando Fast para impressão, certo? Sendo este o caso, por gentileza, qual é p fr3 que está utilizando? O mesmo está em dia com o do SVN? Conferindo na unit que alimenta as variáveis que alimentam o fr3 e comparando com o impresso em Fortes, realmente parece haver divergência na forma como é alimentada o Local da Prestação do Serviço. Foi criada a #TK-3861 para análise do caso e parecer do consultor responsável. No entanto, quanto ao Local de Incidência, em uma primeira análise parece estar tudo correto. Por favor, pode disponibilizar para teste um XML que esteja apresentando problemas? Siga as orientações deste tópico para fazer isso:
  6. until
    Para mais detalhes do evento por favor confira
  7. Boa tarde. Conferindo no Portal da Nota Fiscal Eletrônica, é possível observar que a Sefaz de São Paulo está com contingência agendada para o dia 30/04/2023 com previsão de inicio as 06:00 horas e término as 16:00 horas do mesmo dia. Durante este período, para transmitir notas em contingência, siga as instruções do tópico a seguir: Um agradecimento especial ao membro de nossa comunidade @Jonas_Farsoft pelo aviso.
      • 4
      • Curtir
  8. Boa tarde @phulano. Por favor, pelo Log que disponibilizou, da a entender que você gera o XML a parte e depois o carrega no Monitor para fazer o envio, é isso mesmo? Se for este o caso, por favor, confira no arquivo que está gerando qual valor está passando para a tag xMun do grupo emitente. Passando o arquivo XML que disponibilizou em Sefaz-RS - NF-e Validador de Mensagens do Projeto NF-e, ele acusou o seguinte erro: Schema XML: 225 - Rejeicao: Falha no Schema XML da NFe The 'http://www.portalfiscal.inf.br/nfe:xMun' element is invalid - The value '' is invalid according to its datatype 'String' - The Pattern constraint failed. E se conferirmos no seu XML no grupo enderEmit, ficou vazia a informação:
  9. Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.
  10. Boa tarde. Este campo não consta no leiaute da versão simplificada 1.1 e nem da versão simplificada 1.0(ambas disponíveis para leitura aqui). O evento S-1010 é o evtTabRubrica. Se conferirmos tanto schema evtTabRubrica-v_S_01_00_00.xsd quanto no evtTabRubrica-v_s_01_01_00.xsd não existe mais este campo. Mais informações sobre o porque isso foi removido neste tópico: A versão 2.5 já não é mais aceita pelo WebService do e-Social a muito tempo. Você deve usar a versão simplificada 1.1
  11. Sim, já contempla.
  12. Bom dia. A TK foi atribuída a sprint dessa semana
  13. Bom dia. Mude no seu cedente.ini de TipoPessoa para TipoInscricao. Considerando o ini que anexou, ficaria TipoInscricao=0. Após isso, faça um novo teste.
  14. Foi gerado o arquivo XML? É possível compartilhar para análise? Caso tenha dados sensíveis, siga as orientações deste tópico para disponibilizar:
  15. Verifique se não tem caracteres especiais como & e afins no conteúdo desse XML. Acentos também podem interferir. Revise também como está preenchendo sua aba DFe > Certificado do ACBrMonitor. Este tópico pode ajudar com isso:
  16. Boa tarde. Por favor, qual é o problema que está tendo? Não deu para ver a mensagem completa no print que compartilhou.
  17. Boa tarde! Realmente, estava sendo gerado mesmo quando tpRegTrab do registro S-2200 era diferente de 1. No entanto, não é possível usar o tpRegTrab como parâmetro para geração, pois não temos acesso ao valor dele quando o evento é o S-2205. Por isso, foi enviado ao SVN na Rev-29198 alteração do tipo da propriedade infoCota de tpSimNao para tpSimNaoFacultativo e adicionada regra para que a geração da tag só ocorra se o valor for diferente de snfNada. Em suma, caso não atribua valor a propriedade no componente, não vai mais gerar a tag, ficando assim a critério da sua aplicação definir quando preencher. Por favor, queira atualizar seus fontes, reinstalar o ACBr para realizar novos testes e reportar qualquer problema.
  18. Boa tarde! Por favor, é possível disponibilizar este arquivo XML para testes? Caso tenha informações sensíveis, siga as orientações deste tópico:
  19. Por favor, altere no seu Cedente.ini de Para e faça um novo teste.
  20. Arquivo recebido, farei alguns testes com ele e retorno assim que descobrir algo.
  21. Bom dia! Por favor, é possível disponibilizar esse arquivo cedente.ini que está utilizando para testes? Como tem dados sensíveis, pode seguir as orientações deste tópico:
  22. Bom dia. Mais uma vez, muito obrigado pela contribuição! Fiz alguns testes com ela e no meu entendimento está tudo correto. Por isso, a mesma foi enviada ao SVN na Rev-29194. Por favor, queira atualizar seus fontes, reinstalar o ACBr para realizar novos testes e reportar qualquer problema.
  23. Boa tarde. Foi criada a #TK-3850 para análise do caso e parecer do consultor responsável.
  24. Boa tarde @mgmobile. Por favor, faça um teste enviando CodigoMoraJuros como nome da chave. Mais especificamnete, considerando o exemplo que disponibilizou "CodigoMoraJuros = 1".
  25. Tópico movido conforme requisitado.
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.