Italo Giurizzato Junior

Daniel, Por favor, evite de postar o XML como texto e sim como um arquivo em anexo, desta forma o post fica mais curto. Esse exemplo, não é um envelope e no caso ele esta usando o envio sincrono que inclusive o programa exemplo possui um botão que exemplifica esse tipo de envio.

Leonardo, Maravilha, atualizando os fontes, em breve vou disponibilizar.

Boa tarde Lucas, Não entendi a sua postagem, pois na pasta: ...\Exemplos\ACBrNFSe\Delphi\Schemas\GovBR temos 17 arquivos e na pasta: ...\Exemplos\ACBrNFSe\Delphi\Schemas\Pronim temos 2 arquivos.

Boa tarde Dionatan, Mais uma vez obrigado, assim que possível vou disponibilizar.

Boa tarde Dionatan, Muito obrigado pela colaboração, vou fazer as alterações e assim que possível vou disponibilizar.

Boa tarde Leonardo, Muito obrigado pela colaboração. Assim que possível vou disponibilizar as alterações.

Boa tarde vencetex, Quando você diz que não esta sendo atualizado é o XML do MDF-e, correto? Se sim, é assim mesmo, o XML do MDF-e enviado não é alterado e permanece como autorizado. Lembre-se que o cancelamento do MDF-e é por evento. Quando efetuamos o cancelamento, na verdade estamos enviando um evento que é vinculado ao MDF-e. Logo temos neste caso 2 XML: 1. o XML do MDF-e que acusa que foi enviado e autorizado; 2. o XML do evento de cancelamento que acusa que o evento foi enviado e vinculado ao MDF-e. Veja o programa exemplo, ele possui um botão para imprimir evento, onde você carrega os dois XMLs e depois imprimir o evento.

Boa tarde Jorge, Assim que possível vou analisar os arquivos.

Boa tarde Daniel, Entre em contato com o provedor e solicite um exemplo de um XML Envelope de envio.

Boa tade Plínio, Usando as suas palavras, estou estudando as suas "gambiarras". Acredito que existe uma maneira mais simples de implementar.

Boa tarde infoel, No caso da NFS-e não existe um webservice para consultar a situação da nota. O que temos é a possibilidade de consultar as notas de um periodo e o que temos como retorno são as notas, se elas foram canceladas, vai conter no XML o grupo com as informações sobre o cancelamento.

Boa tarde Leonardo, Essas URLs se referem ao ambiente de Homologação ou Produção?

Boa tarde, Você esta com todos os fontes de todas as pastas atualizados? Você tem o Quick Report instalado no Delphi?

Boa tarde Binho, Muito obrigado, vou alterar o fonte e disponibilizar assim que possível.

Boa tarde Geo, Muito obrigado pela colaboração. Vou atualizar os fontes e assim que posível, vou disponibilizar.

Boa tarde ALA, Configure o componente para salvar os arquivos de retorno que contem o -c no nome. Quando aparece essa mensagem de erro, um dos motivos é que não foi possuivel ler o arquivo de retorno. O provedor Pronim é uma variação do GovBR leia o meu post anterior.

Boa tarde a todos, Lembrem-se que a CC-e, o Cancelamento são eventos. Ao realizar uma consulta, alem de nos retornar a situação atual da NF-e junto a SEFAZ, vem também todos os eventos vinculados a mesma. Consequentemente se a NF-e possui uma CC-e, teremos essa informação no retorno da consulta. Pelo mesmo é assim que deve funcionar, conforme consta no manual.

Boa tarde Graça e Gustavo, Precisamos rever o DACTE - A5, não tive tempo ainda.

Boa tarde Hugo, Fiz algumas alterações, favor atualizar os fontes e testar novamente. Favor entrar em contato com o provedor e solicitar as URLs tanto do ambiente de homologação quanto de produção. As de produção acredito que descobri as corretas, mas de homologação não.

Boa tarde ALA, Alterei a cidade de Contagem para o provedor Pronim. Favor atualizar os fontes novamente e configurar o componente para utilizar os schemas da pasta Pronim para a cidade de Contagem. Realize os testes novamente.

Boa tarde jwester, Favor atualizar os fontes e testar novamente.

Boa tarde Gary, Favor atualizar os fontes e testar novamente.

Boa tarde Daniel, Favor atualizar os fontes e tentar novamente.

Binho, Para você ver que algumas dessas empresas que oferecem para as prefeituras o serviço de webservices de NFS-e são amadoras, note: Em particular o provedor mencionado por você. 1. No Schema temos a definição da TAG: IncentivadorCultural no grupo de informações do RPS <xsd:element name="IncentivadorCultural" type="tsSimNao" minOccurs="1" maxOccurs="1"/> 2. Definição do tipo simples: tsSimNao <xsd:simpleType name="tsSimNao"> <xsd:restriction base="xsd:byte"> <xsd:pattern value="1|2"/> </xsd:restriction> </xsd:simpleType> 3. Concluimos que a TAG IncentivadorCultural é obrigatória, uma vez que o minOccurs é igual a 1 e cujo valor será 1 ou 2, para Sim ou Não respectivamente. 4. No Schema temos a definição da TAG: IncentivadorCultural no grupo de informações da NFSe: <xsd:element name="IncentivadorCultural" type="tsSimNao" minOccurs="1" maxOccurs="1"/> 5. Também do mesmo tipo e obrigatório. 6. Se nós fossemos validar os XMLs de retorno, o XML referente a NFS-e que você anexou, não seria validado pois não consta essa TAG no mesmo. Fica aqui a pergunta, quem esta errado? Até quando vamos ter que fazer gambiarras, pois essas empresas não geram o XML conforme o schema. Cada vez mais ,acredito da seguinte frase: Faça o que eu mando, mas não faça o que eu faço. Ou seja, nós temos que gerar o XML do jeito que eles querem, mas o retorno eles fazem de qualquer jeito.

Boa tarde Hugo, Favor atualizar os fontes e testar novamente.