Italo Giurizzato Junior

Bom dia Ricardo, Se você não alimentar o componente com essa informação e se a tag for opcional, ela não será gerada.

Bom dia Graça, Muito obrigado pela colaboração, aproveitei e fiz o mesmo em outros "case". Já enviei para o repositório.

Bom dia ALA, Você entendeu a minha ultima postagem? Eu escrevi: é só isso. E aproveito para lhe informar que você esta com os seus fontes desatualizados em especial os arquivos INI. Comparando os arquivos INI que você anexou com os que estão no repositório, por exemplo o arquivo Cidades.ini que esta no repositório tem um tamanho de 77 Kbytes já o seu tem apenas 64 Kbytes, o GINFES.ini então, esta muito desatualizado. Se a cidade contratou o GINFES é obvio que os schemas a serem utilizados são os da pasta GINFES, não pode usar outro.

Bom dia Adriano, A rejeição esta ocorrendo por parte do componente ou por parte do provedor? Se no Schema consta que um campo é obrigatório e ele não é gerado no XML ocorre erro de validação antes do RPS ser enviado. Por outro lado se no Schema consta que o campo é opcional, logo não é gerado, mas no webservice ele é esperado mesmo com valor zerado, ai temos um erro de validação por parte do servidor. Neste caso o Schema esta errado, pois deveria estar em conformidade com o que o webservice espera receber.

Bom dia Windel, Você tem certeza que os seus fontes estão atualizados? veja: (...) proActconv202, proSigep, proSafeWeb, proSH3, proSIAPNet, proIPM, proBelford, proISSJoinville, proAsten, proELv2);

Bom dia Jarbas, O ponto e virgula é usado pelo componente ACBr, no site com certeza não vai funcionar. É preciso obter o XML de uma NFS-e feita através do site cuja a descrição possua quebras de linha para saber o que foi utilizado.

Bom dia Hugo, Nos meus testes usei o libWinCrypt.

Bom dia, Ocorreu atualização dos fontes ACBr? Se sim, a aplicação foi recompilada e a partir dai começou o problema? Ocorreu atualização do Windows? Ou simplesmente do nada surgiu o problema?

Bom dia Mauro, Muito obrigado pela colaboração, já enviei para o repositório.

Bom dia, Tentou reinstalar novamente os componentes?

Bom dia Adileine, Você configurou o componente para poder realizar a Declaração do MDF-e? O componente possui uma propriedade de configuração chamada TipoDoc que pode receber os seguintes valores: tdCTe, tdNFe, tdMDFe e tdAddBackMail Use o programa exemplo para testes, configure essa propriedade com o valor tdMDFe e no botão [Criar/Enviar] ao pedir o XML do CT-e/NF-e selecione o XML do MDF-e.

Bom dia a todos, E tem mais, esse CT-e contem os grupos Expedidor e Recebedor, grupos estes que só devem aparecer no XML quando se tratar de Redespacho ou Redespacho Intermediário.

Jorge, Você tem certeza que todos os fontes de todas as pastas estão atualizados? Se sim, após a atualização, os componentes foram reinstalados?

Bom dia a todos, Primeiramente, peço desculpas se fui grosso. Com relação a função LoadFromString é preciso ser checada, pois realmente ela esta estranha, não só por conta das variáveis N e P, existe mais uma coisa que esta errada nela. Que só será notado caso tentarmos ler um XML que contem dois ou mais eventos Reinf. O código aberto nos da essa chance de mais pessoas poderem estudar e apontar erros e sugerir soluções. A finalidade de TEventos.LoadFromString é extrair de uma String o conteúdo do grupo <Reinf>, esse conteúdo é passado para a função: TReinfEventos.LoadFromString que por sua vez procura detectar o tipo de evento se trata. Detectado o evento, o conteúdo é ADD a lista do tipo de evento em questão. O conteúdo que estou me referindo é o XML de um evento Reinf que tem que estar assinado, pois na lista que mencionei acima só ficam os eventos assinados, portanto prontos para serem enviados. No fórum existem pessoas dispostas a colaborar financeiramente assinando o SAC, outras testando o componente, detectando falhas e disponibilizando as devidas correções. Sei muito bem que existem pessoas que tem mais dificuldades e outras menos em compreender o código, isso é normal. O que nós do ACBr, em particular eu quero, é que todos cresçam, evoluem no conhecimento, pois eu também estou aqui para aprender.

Bom dia Jorge, No programa exemplo após mudar o tipo do empregador para teOrgaoPublico, você clicou no botão salvar a configuração?

Boa noite Claudio, Já enviei uma alteração que acredito que vai resolver o problema. Favor atualizar os fontes e faça novos testes.

ALA, É só isso. De: Provedor=Pronim Para: Provedor=GINFES Faça essa alteração e faça os testes.

Jorge, Ao configurar o componente (programa exemplo) você informou corretamente o tipo de empregador ?

ALA, Atualiza os fontes e faça um novo teste.

Bom dia Leonard, Os seus testes estão sendo feitos com o programa exemplo?

Bom dia Hugo, Favor atualizar os fontes e faça novos testes.

Bom dia ALA, Favor anexar o XML da NFS-e.

Bom dia Ricardo, Pode ser que para o provedor em questão é preciso informar de forma diferente. Entre em contato com a prefeitura e com o provedor para saber como deve ser informado o CNAE.

Bom dia Lucas, O problema é que o provedor 4R não implementou no ambiente de homologação o webservice de Consulta ao Lote, somente no ambiente de produção. Se você abrir o arquivo 4R.ini vai notar a falta da URL para esse serviço. Favor entrar em contato com o provedor e questionar sobre isso.

Bom dia a todos, Fernando, isso funciona porque o provedor em questão se utiliza da versão 1 do layout da ABRASF. Se amanhã mudar o provedor e este usa a versão 2, o método ConsultarSituação vai falhar, pois como dito os provedores que seguem a versão 2 do layout da ABRASF não implementaram o método Consultar a Situação do Lote.