Italo Giurizzato Junior

Bom dia Nelson, Desculpe, não quero ser chato, mas essa postagem é para discutirmos sobre as alterações publicadas na NT 2018/002. Vamos procurar sempre seguir as regras do fórum. Com relação ao DACTE faça as alterações que você juga ser necessárias e faça os testes, funcionando conforme o esperado, criei um novo tópico anexe a unit alterada e descreva a motivação dessa alteração. Desde já muito obrigado pela colaboração.

Bom dia Anderson, Você chegou a enviar o evento 2099? Nos XML que você anexou vejo que só foi enviando o evento 1000. Para obter o Numero do Protocolo de Fechamento a ser utilizando no Consultar é preciso enviar o evento de Fechamento, ou seja, o evento 2099.

Boa tarde Rafael, Esses arquivos você recebeu por e-mail? Pois estão muito estranhos, foi preciso editar para remover sujeiras.

Boa tarde Paulo, Muito obrigado pela colaboração, vou fazer a alteração e enviar para o repositório ainda hoje.

Rodrigo, No layout do XML do respectivo provedor não existi nenhuma tag chamada Estado, isso me faz a crer que a mensagem de erro se refira a tag Uf do prestador de serviço. Mas pelo que pude ver esta OK. Favor entrar em contato com o provedor e questioná-los sobre esse erro.

Boa tarde, Favor anexar o XML de pedido de cancelamento para que possamos analisar.

Boa tarde Rodrigo, Favor anexar o XML do RPS, pois o mesmo foi processado com falha.

Boa tarde, Você esta com todos os fontes de todas as pastas atualizados? Pois segundo o arquivo INI do provedor ele possui os métodos Enviar, Consultar Lote e Cancelar implementados pelo provedor em seu Webservice.

Boa tarde Rodrigo, Eu não tenho nenhum cliente nessa cidade que emite NFS-e, logo se ninguém me avisar que a respectiva cidade mudou de provedor, como é que vou ficar sabendo? Vamos lá, você tem a força, faça a alteração no arquivo Cidades.ini e se necessário no arquivo INI do novo provedor. Faça os testes e estando tudo OK por favor anexe os arquivos alterados para que possamos avaliar e estando tudo certo vamos enviar para o repositório. Desde já agradeço a sua colaboração.

Bom dia Reinando, Você deve ter baixando o XML diretamente do site da SEFAZ, correto? Se sim, esse é o grande problema. Infelizmente não temos como obrigar a SEFAZ fazer o dever de casa.

Bom dia Anderson, A consulta só pode ser realizada depois que você envia o evento de fechamento, note que no XML de consulta (*-ped-sit.xml) devemos informar o numero do protocolo de fechamento.

Bom dia Mauricio, Desde já muito obrigado pela colaboração, vamos analisar e caso esteja tudo OK vamos enviar para o repositório.

João, O problema ocorre na validação do webservice, pode ser que eles mudaram os schemas de validação e nós ainda temos os antigos.

Boa tarde João, Note que o RPS foi gerado, o Lote foi gerado, assinado, validado e enviado. A mensagem de erro esta presente no retorno, sendo assim é o validador do Webservice que esta com problemas. Ou esqueceram de incluir o campo Discriminacao ou ele esta com a grafia errada no Webservice. Favor entrar em contato com eles e solicitar a correção.

Boa tarde, Quais são as cidades atendidas por esse provedor? Você tem documentação do mesmo? XMLs exemplos? URLs de homologação e produção? Schemas para validar o lote antes do envio?

Boa tarde Rauber, O programa exemplo esta configurado para usar os schemas da pasta: ...\Exemplos\ACBrDFe\ACBrNFSe\Schemas\Publica ?

Boa tarde Raylan, O componente não gera o XML da NFS-e, apenas o XML do RPS e o envia para o provedor, este por sua vez processa e se tudo estiver OK gera e retorna o XML da NFS-e. É assim que todos os provedores procedem, o EL não faz isso?

Boa tarde Wanderson, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Boa tarde Rafael, No caso de Concordia/SC basta acrescentar a cidade no arquivo Cidades.ini da mesma forma que as demais. E iniciar os testes usando o programa exemplo. Já esses provedor contratado pela cidade Nonoai/RS favor solicitar um XML de exemplo completo que é enviado contendo o RPS. O arquivo de schema nfse,xsl esta estranho pois contem "3D" em varias definições dos tipos. exemplo: <xsd:simpleType name=3D"tsNumeroNfse"> <xsd:restriction base=3D"xsd:nonNegativeInteger"> <xsd:totalDigits value=3D"15" /> </xsd:restriction> </xsd:simpleType> Nunca vi isso antes.

Boa tarde Francisco, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Boa tarde Anderson, Faça um teste usando o programa exemplo, pois acabei de fazer e não ocorreu esse erro.

Boa tarde Gustavo, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Boa tarde Hernandes, Segundo a Nota Técnica 2018/002 isso esta previsto para o modal aéreo e faz referencia ao CT-e e não a NF-e. Portanto acredito que o que você deseja fazer não seja possível, apesar de não ter encontrado nenhuma regra de validação que rejeita um segundo MDF-e fazendo referencia a mesma chave da NF-e informada em outro MDF-e.

Bom dia, Muito obrigado pela colaboração, vou incluir essas alterações juntamente com o que estou fazendo em virtude da NT 2018/002. Assim que possível vou enviar tudo para o repositório.

Boa tarde Leandro, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.