Italo Giurizzato Junior

Com base no WDSL do serviço temos: <s:element name="EntregaDocumentacao" maxOccurs="1" minOccurs="1" type="s1:TipoEntregaDocumentacao" nillable="true"/> Essa tag é obrigatória e seus valores estão definidos em TipoEntregaDocumentacao: <s:simpleType name="TipoEntregaDocumentacao"> <s:restriction base="s:string"> <s:enumeration value="RedeCredenciada"/> <s:enumeration value="Cliente"/> </s:restriction> </s:simpleType> A URL do WDSL é: https://dev.efrete.com.br/Services/PefService.asmx?WSDL que me parece ser do ambiente de testes. A minha duvida é quanto ao: nillable="true", como não domino os XSD e fazendo uma pesquisa rápida na internet cheguei a conclusão que a tag TipoEntregaDocumentacao poderá ter um valor nulo, ou seja, ser gerada sem nenhuma informação.

Bom dia Camilo, A sua aplicação esta apontando para uma pasta de schemas, essa pasta esta com os mesmos XSD que estão na pasta que o programa exemplo se utiliza? Pois o erro que você postou na sexta feira indica schema desatualizado.

Bom dia Rejane, Essa tag não deve ser gerada em nenhuma hipótese, pois ela não existe mais, ou depende de alguma condição? Infelizmente o manual do eFrete não esta atualizado, ele alteram no inicio que o que foi alterado, mas não atualizam o layout dos serviços. Se você seguir a risca o layout do manual nada funciona.

Bom dia Pereira, O Windows tem os seus mistérios. Se tudo o que lhe foi orientado a fazer foi feito e não resolveu o problema. Não vejo outra saída formatar a maquina e instalar o Windows novamente. Mas cuidado, tem versões do Windows que a coisa não funciona, procure sempre instalar a versão profissional. Tive um problema parecido no meu cliente, foi instalado uma versão "sabe Deus qual" do Windows e a coisa não andava. Pedi para formatar novamente e instalar a versão profissional, resolveu o problema.

Bom dia Leonardo, Atualizou e fez novos testes? Deu certo, esta imprimindo todas as guias?

Boa tarde Joas, Vou descomentar as linhas e enviar para o repositório para que o pcnNFeW continue compatível com a versão anterior a 4 da NF-e. Pois na versão 3.10 se o produto não possuía o código tínhamos que atribuir uma string vazia a cEAN. Mas o recomendado é sempre alimentar o componente com os dados corretos.

Bom dia Joas, No primeiro momento essas linhas foram comentadas pois a regra não tinha sido implementada. E após a sua implementação muitos desenvolvedores colocaram essa condição em suas rotinas que alimentam o componente. Temos dois caminhos a seguir: 1. Na rotina que alimenta o componente, informar os dados corretos como por exemplo a questão do GTIN, que ao ler o código do cadastro do produto alimentar o componente com o código lido ou na sua ausência alimentar com o literal "SEMGTIN" (que ao meu ver é o mais correto). 2. Ou deixar por conta do componente fazer as devidas correções que as vezes podem não ser a mais correta. Pois esse IF que esta comentado se for descomentado ele vai gerar o literal "SEMGTIN" na tag cEAN caso esse campo no componente não venha a ser alimentado. A nota talvez seja autorizada, mas e se o produto realmente tem um código?

Bom dia Joas, Acredito que no seu caso o problema seja a falta de atualização do Windows.

Bom dia Camilo, São 2 coisas que você deve verificar: 1. A configuração do componente: o Valor de SSLType deve ser TL_TLSv1_2 2. A atualização do Windows, baixar e instalar todas as que estão pendentes.

Bom dia Rodrigo, Muito obrigado pela colaboração, esta tudo OK, vou enviar para o repositório juntamente com outras alterações.

Bom dia Maiquel, A sua alteração esta correta, já vou enviar para o repositório junto com outras alterações. Mais uma vez muito obrigado pela contribuição.

Sefaz suspende exigência do CEST em documentos fiscais A Secretaria de Fazenda (Sefaz) suspendeu o início da exigência do Código Especificador da Substituição Tributária (CEST) nas notas fiscais Eletrônica (NFe) e de Consumidor Eletrônica (NFCe). A obrigatoriedade da informação do CEST nos documentos fiscais estava prevista para vigorar a partir do dia 1º de junho de 2020. A medida foi adotada devido ao momento vivido no país com a pandemia do novo coronavírus – Covid-19, conforme orientação da Coordenação Nacional do Encontro Nacional dos Administradores Tributários – ENCAT. Segundo a Coordenação, a validação do CEST será implementada futuramente. A aplicação da regra da validação do CEST consta na Nota Técnica 2015/003 versão 1.94. O Código foi instituído no Convênio ICMS 92/2015 e deve ser informado utilizando o NCM/SH. Essa Noticia foi extraída do site da SEFAZ-MT.

Boa noite Leonard, Em uma passada rápida: 1. Tem um layout próprio; 2. A montagem do arquivo não é em XML e sim em JSON. O componente ACBrNFSe só trabalha com XML, tanto para envio quanto para retorno.

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

Boa tarde Valter, Favor atualizar todos os fontes de todas as pastas, reinstale a suíte ACBr com o ACBrInstall_Trunk2 com a opção de apagar arquivos antigos marcada. Faça novos testes usando o programa exemplo.

Boa tarde Valter, O componente ACBrNFSe gera o XML do RPS e envia para o provedor (empresa contratada pela prefeitura). O Webservice do provedor processa o RPS e se tudo estiver OK gera o XML da NFS-e. Para obter o XML da NFS-e se faz necessário uma consulta. O componente possui 3 métodos de consulta: ConsultarLote, ConsultarNFSePorRps e ConsultarNFSe. No primeiro você informa o numero do lote e o protocolo, no segundo você informa o numero, serie do RPS, já o terceiro se faz necessário saber o numero e serie da NFS-e, sendo assim este ultimo é útil quando você perde o XML e deseja baixar ele novamente. Normalmente usamos o ConsultarLote, uma vez que o numero do lote é gerado pelo emitente e o protocolo é retornado automaticamente logo após o envio. O componente possui uma propriedade de configuração chamada: ConsultaLoteAposEnvio. Se o valor dela for True, o componente se encarrega de realizar todo o processo, ou seja, envia o RPS, aguarda o retorno, consulta o lote para obter o XML da NFS-e. Andes de sair escrevendo a sua aplicação, faça os testes com o programa exemplo do componente.

Boa tarde Maiquel, Já inclui na minha lista, espero até o final desta semana analisar a sua contribuição e estando tudo OK, vou enviar para o SVN. Desde já muito obrigado.

Boa tarde Maiquel, No programa exemplo tentou a seguinte configuração?

Boa tarde Windel, Para implementar, a principio basta criar um arquivo INI para esse provedor (Citta.ini) aos moldes de outros provedores que seguem a versão 2 do layout da ABRASF. Na unit pnfsConversao criar um enumerador para o provedor (proCitta) e alterar alguns métodos dessa unit segundo o que foi feito para os demais provedores da versão 2 do layout da ABRASF. No arquivo Cidades.ini configurar essa cidade para o respectivo provedor. Por fim iniciar os testes com o programa exemplo. Talvez seja necessário (e os testes vão mostrar isso) fazer alterações na unit pnfsNFSeW_ABRASFv2.

Boa tarde Walney, Se você vai usar o ACBrMonitor, te aconselho a gerar o arquivo INI segundo o layout da ACBr e não o arquivo XML. Te garanto, você vai ter menos dor de cabeça.

Boa noite Datilas, Isso esta correto: C:\xx\19\05\20 15:14:\ ?

Maiquel, Com o programa exemplo ocorre o mesmo problema?

Boa noite Carlos, Em alguns provedores onde tivemos erro de assinatura invalida o motivo era o namespace, por exemplo. Se informar o namespace http://www.abrasf.org.br/ a assinatura é considerada valida pelo provedor, por outro lado se informar o namespace http://www.abrasf.org.br/nfse.xsd o provedor acusa que a assinatura é invalida. Se o provedor nos fornecer um XML completo para realizar a substituição vai ficar mais fácil descobrir onde estamos errando.

Boa tarde ederts, Muito obrigado pela colaboração, já enviei para o repositório.

Maiquel, Acabei de enviar uma correção no arquivo INI do provedor Fiorilli. Favor atualizar e faça novos testes.