Italo Giurizzato Junior

Bom dia, Necessito de um exemplo completo (Envelope) de envio da nota para o webservice. Não basta o XML da nota, tem que ser completo, assim vai ser possível ter uma ideia de como devemos gerar o XML antes de ser enviado para o webservice. Outra coisa não temos os arquivos XSD (Schemas) desse provedor, logo fica complicado gerar o XML e enviar sem realizar a validação. Trabalhar sem os schemas é implementar na tentativa e erro.

Boa tarde Beto, A tag cUnid no MDF-e só aceita os valores 01= KG e 02 = TON. No programa exemplo temos: // UnidMed = (uM3,uKG, uTON, uUNIDADE, uLITROS); tot.cUnid := uTon; O comentário acima que apresenta os valores possíveis esta errado, o correto será mostrar somente os valores uKG e uTON. Os demais valores se não me falha a memória são aceitos no CT-e.

Boa tarde Maiquel, É preciso saber se essa alteração não vai gerar efeito colateral para outras cidades que utilizam o mesmo provedor. O que você fez foi tornar a tag opcional para quando a alíquota for zero. Essa regra é valida para todas as cidades?

Boa tarde a todos, Com certeza é erro no webservice deles.

Boa tarde Carlos, Essas mensagens ocorrem quando não foi gerado a mensagem de dados que vai ser enviado para o webservice ou não existe no arquivo INI do provedor a definição do Envelope para o serviço que se deseja utilizar. A titulo de exemplo o Gerar, veja o arquivo INI do provedor como esta: [Gerar] IncluiEncodingCab=0 IncluiEncodingDados=0 TagGrupo= TagElemento=nfse DocElemento= InfElemento= Texto1= Não tem a definição do Envelope, veja agora de um outro provedor: [Gerar] IncluiEncodingCab=0 IncluiEncodingDados=0 Texto1=<S:Envelope xmlns:S="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:ws="http://nfse.abrasf.org.br"> Texto2=<S:Body> Texto3=<ws:GerarNfseRequest> Texto4=<nfseCabecMsg>%CabMsg%</nfseCabecMsg> Texto5=<nfseDadosMsg>%DadosMsg%</nfseDadosMsg> Texto6=</ws:GerarNfseRequest> Texto7=</S:Body> Texto8=</S:Envelope> Resumindo, o arquivo INI desse provedor esta incompleto.

Boa tarde Maiquel, A priori somente isso, mas se não esta funcionando vai ser preciso debugar para descobrir o motivo dele não obedecer.

Boa tarde Edson, No programa exemplo do componente ACBrNFSe, mais precisamente na aba WebServices temos um CheckBox onde podemos ativar a gravação do SoapEnv. [ ] Salvar Envelope Soap No caso do envio do lote vai ser salvo um XML com o seguinte nome: *-env-lot-soap.xml É esse o arquivo que eles querem.

Boa tarde Edson, Se o EnviarSincrono retornou False pode ser que o RPS não foi aceito é preciso verificar o motivo da rejeição e fazer as devidas correções e enviar novamente.

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

Boa tarde Igor, Já esta no repositório o arquivo corrigido.

Bom dia Igor, Realmente fiz essa alteração no arquivo INI de forma indevida. O que ocorre: No XML do RPS tem que constar o NameSpace, o componente se utiliza o informado no campo: NameSpace da seção: XML O problema é que alguns provedores o NameSpace que deve ser informando no XML do RPS para ser assinado não deve conter o nome do arquivo XSD. Por outro lado ao gerar a mensagem de dados a ser enviada para o webservice esta tem que ter o NameSpace e este tem que conter o nome do arquivo XSD. Resumindo, para o provedor Goiania o NameSpace tem ser: Para o RPS: http://nfse.goiania.go.gov.br/xsd/ Para a mensagem de dados: http://nfse.goiania.go.gov.br/xsd/nfse_gyn_v02.xsd Vou providenciar a correção e enviar para o repositório. Muito obrigado por detectar a minha falha.

Bom dia Cleiver, Sem essa alteração a nota é autorizada pela SEFAZ ou é rejeitada? Se é rejeitada qual é o código e descrição da rejeição?

Boa noite Carlos, Por favor atualize todos os fontes de todas as pastas, depois veja o programa exemplo. Nele esta assim: // TMDFeTpEmitente = ( teTransportadora, teTranspCargaPropria ); Ide.tpEmit := teTransportadora; Ide.modelo := '58'; Ide.serie := 1; Ide.nMDF := StrToIntDef(NumDFe, 0); Ide.cMDF := GerarCodigoDFe(Ide.nMDF); Leia também o artigo do link a seguir: Apesar dele se referir a NF-e, mas é exatamente isso que esta ocorrendo com o seu MDF-e. Leia também esse outro:

Boa tarde Giliard, Esses arquivo XSD não é o que consta no repositório pasta: ...\Exemplos\ACBrDFe\ACBrNFSe\Schemas\ELv2 Favor atualizar todos os fontes de todas as pastas e use os schemas distribuídos por nós. Pois tem vários casos que os XSD dos provedores contem erros e nós fazemos as devidas correções e atualizamos o repositório. Esse XSD foi corrigido por mim em 19/03/2018 e a correção foi exatamente no elemento CompNfse.

Boa tarde, Em um rápida pesquisa na internet achei essa informação sobre o erro 401, segue o link: https://www.redehost.com.br/duvidas/erro-401-no-autorizado-como-resolver--1615 Tem provedor que requer que seja feito um cadastro para que seja possível emitir as notas via webservice. Uma coisa é ter usuário e senha para emitir via site, outra coisa e ter permissão para emitir via webservice.

Bom dia Emanuel, No XML da NF-e/NFC-e contem a Chave de Acesso que é gerada automaticamente pelo componente ACBrNFe. É com essa chave que devemos trabalhar, pois ela é utilizada em consultas e eventos, tais como: Carta de Correção, Cancelamento e outros. Por outro lado a Chave Natural é gerada e controlada pela SEFAZ-Autorizadora, antes essa chave no que diz respeito a NF-e aceitava somente o CNPJ, com a possibilidade de uma pessoa física poder emitir uma NF-e a SEFAZ fez alterações em seu sistema para que a Chave Natural contemplasse o CPF também. Hoje a Chave de Acesso da NF-e contem as seguintes informações: Código IBGE da UF do Emitente (2 dígitos), Ano (2 dígitos), Mês (2 dígitos), CNPJ ou CPF (14 dígitos), Modelo (2 dígitos), Serie (3 dígitos), Numero (9 dígitos), Tipo Emissão (1 digito), Código Aleatório (8 dígitos) e Digito Verificador (1 digito). Totalizando 44 dígitos. A diferença para a NFC-e é que somente o CNPJ é aceito na chave. O que diz a NT a respeito da Chave Natural? Para a NF-e ela será composta por: UF, CNPJ ou CPF do Emitente, Série e Número da NF-e, modelo do documento fiscal eletrônico e ambiente de autorização. Para a NFC-e: UF, CNPJ do Emitente, Série e Número da NF-e, modelo do documento fiscal eletrônico e tipo de emissão. No caso da NF-e onde esta escrito ambiente de autorização leia-se tipo de emissão. Veja que eu coloquei em negrito as informações que estão na Chave de Acesso e que são utilizados pela SEFAZ para montar a Chave Natural. Resumindo: Ninguém precisa se preocupar com essa alteração que a SEFAZ esta promovendo em seu ambiente.

Bom dia Maiquel, Acredito que para resolver esse problema seja necessário fazer uma pequena alteração no arquivo INI do provedor. Note que tanto na seção [Gerar] quanto na [RecSincrono] não temos os campos: DocElemento e InfElemento Experimente fazer a seguinte alteração: [Gerar] IncluiEncodingCab=0 IncluiEncodingDados=0 DocElemento=tcDeclaracaoPrestacaoServico InfElemento=InfDeclaracaoPrestacaoServico Texto1=<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> (...) O mesmo para o [RecSincrono]

Bom dia Giovane, Por outro lado a unit pnfsNFSeG existe a muito mais tempo e é nela que consta as rotinas que são gerados as consultas, o cancelamento entre outras. Como o provedor Elotech segue a ABRASF a unit pnfsNFSeW_Elotech nem deveria existir.

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

Bom dia Carlos, Sugiro você deixar de lado a nova versão do componente que se encontra no Branches pois todos os dias estou fazendo alterações nele. O componente atual que se encontra no Trunk2 emite NFS-e de por volta 85 provedores que seguem o layout da ABRASF e de uns 20 que não seguem. A titulo de exemplo temos os provedores: Equiplano, Governa, Siat, entre outros. Não me recordo quem começou a escrever a unit mas tenho a unit que gera o XML, segue em anexo. pnfsNFSeW_SigISS.pas Não sei se esta completa ou não, mas se você tem o manual com o layout do XML que deve ser enviado, já da para deixar a unit acima pronta para gerar o mesmo. Me parece que o componente já reconhece esse provedor, sendo assim, basta fazer as alterações necessárias na unit em anexo e iniciar os testes com o programa exemplo.

Edson, Não, gerar o RPS e imprimir o recibo é caso o sistema que recepciona a nota estiver com problemas. O cliente ir embora com o Recibo é uma exceção, em via de regra ele tem que ir embora com a nota em mãos.

Edson, Se não me falha a memória em caso de falha, ou seja, o webservice que recepciona a NFS-e esta parado, a solução é gerar o RPS e imprimir uma espécie de Documento Auxiliar do RPS. Lembrando que o RPS é um Recibo Provisório de Serviço, sendo assim, logo que sanarem os problemas devemos envia-lo para o webservice. A impressão desse DARPS também não foi implementado no componente. Veja o que consta no manual da NFS-e versão 1 do layout da ABRASF: 2.2 RECIBO PROVISÓRIO DE SERVIÇO - RPS A NFS-e somente será gerada através dos serviços informatizados disponibilizados pelas Secretarias Municipais de Fazenda. Esse tipo de serviço é seguido de alguns riscos inerentes à ininterrupta disponibilidade, podendo, portanto, em alguns momentos tornar-se indisponível. Visando manter as atividades dos contribuintes ininterruptas, independente de os serviços informatizados disponibilizados pelas Secretarias Municipais de Fazenda estarem disponíveis, foi criado o Recibo Provisório de Serviços (RPS), que é um documento de posse e responsabilidade do contribuinte, que deverá ser gerado manualmente ou por alguma aplicação local, possuindo uma numeração sequencial crescente e devendo ser convertido em NFS-e no prazo estipulado pela legislação tributária municipal.

Boa tarde Luiz, O maior problema é que o RPS é assinado e o Lote também, agora fica a duvida o webservice esta recusando qual das duas assinaturas (RPS ou Lote)?

Boa tarde Alexandre, O arquivo Cidades.ini não contem a cidade Volta Redonda/RJ. Da forma que você acrescentou esta correto. Não se faz necessário alterar nada no arquivo INI do provedor, veja. [URL_P] RecepcaoLoteRPS=http://www.issnetonline.com.br/webserviceabrasf/%NomeURL_P%/servicos.asmx [URL_H] RecepcaoLoteRPS=http://%NomeURL_H%.issnetonline.com.br/webserviceabrasf/homologacao/servicos.asmx No campo RecepcaoLoteRPS da seção URL_P o componente automaticamente substitui a string "%NomeURL_P% pelo seu valor que esta no arquivo Cidades.ini que no caso é voltaredonda. Consequentemente o resultado final vai ser: http://www.issnetonline.com.br/webserviceabrasf/voltaredonda/servicos.asmx Apesar da URL começar com http em vez de https vai funcionar da mesma forma. O que você tem que faze é iniciar os testes usando o programa exemplo do componente.

Boa tarde Edson, Como disse o Juliomar, é preciso verificar junto a prefeitura se ela aceita um DANFSE emitido em bobina em fez de folha A4. Se aceitar vai ser necessário implementar, pois o componente não tem esse modelo de DANFSE. Neste caso aconselho implementar usando o EscPos, aos moldes que foi feito o DANFE da NFC-e.