Italo Giurizzato Junior

Bom dia, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Bom dia Sérgio, Vou verificar o motivo de ter alterado de 90 para 91, mas fazendo da forma que lhe mostrei não é para ocorrer erros.

Bom dia Luiz, O componente gera a chave (identificação única do evento) e a utiliza para compor o nome do XML a ser salvo em disco, veja: A identificação única do evento (Id) é composta por 36 caracteres, conforme o que segue: IDTNNNNNNNNNNNNNNAAAAMMDDHHMMSSQQQQQ ID - Texto Fixo "ID"; T - Tipo de Inscrição do Empregador (1 - CNPJ; 2 - CPF); NNNNNNNNNNNNNN - Número do CNPJ ou CPF do empregador - Completar com zeros à direita. No caso de pessoas jurídicas, o CNPJ informado deve conter 8 ou 14 posições de acordo com o enquadramento do contribuinte para preenchimento do campo {ideEmpregador/nrInsc} do evento S-1000, completando-se com zeros à direita, se necessário. AAAAMMDD - Ano, mês e dia da geração do evento; HHMMSS - Hora, minuto e segundo da geração do evento; QQQQQ - Número sequencial da chave. Incrementar somente quando ocorrer geração de eventos na mesma data/hora, completando com zeros à esquerda. OBS.: No caso de pessoas jurídicas, o CNPJ informado deverá conter 8 ou 14 posições de acordo com o enquadramento do contribuinte para preenchimento do campo {ideEmpregador/nrInsc} do evento S-1000, completando-se com zeros à direita, se necessário.

Bom dia Moreira, O campo <aliqRatAjust> segundo o Manual ele é opcional, como você atribuiu o valor zero (aliqRatAjust=0,00) a esse campo, no XML a tag não foi gerada. Quando a outra mensagem de erro, o motivo é que consta no arquivo a seção [infoObra] sendo que não deveria. [infoObra] indSubstpatrObra=2

Bom dia, Note que o retorno do envio (arquivo *-recS.xml) já contem o XML da NFS-e. Nesse XML não consta a tag protocolo, isso explica o fato da imagem (primeira postagem sua) essa informação aparecer em branco. O protocolo esta presente no retorno do envio quando o provedor segue a versão 1 do layout da ABRASF e utilizamos essa informação para consultar a situação do lote. Já o provedor SIAPNet segue a versão 2, e nessa versão não existe a consulta a situação do lote. Mas o componente deve conter alguma falha pois ao extrair do retorno o XML da NFS-e e salva-lo separadamente (arquivo *-nfse.xml) não esta conseguindo extrair, logo o conteúdo do arquivo *-nfse.xml esta "vazio". Vou verificar o motivo desse problema e fazer as devidas correções. Assim que enviar para o repositório os fontes do componente com uma possível correção, lhe aviso.

Configura para salvar os arquivos Soap. Configuracoes.webservices.salvar := True; Faça um novo teste e anexa os arquivos de envio e de retorno.

Renato, No seu XML temos 3 ocorrências do grupo <dmDev> sendo que somente na primeira ocorrência consta o grupo <itensRemun>, sendo que este grupo conforme consta no manual ele é obrigatório e podendo ocorrer de 1-200 vezes para cada <dmDev>. Dai o motivo do erro.

Esse arquivo que você anexou tem: "<?xml version="1.0"?>" não é para ter nada disso.

Boa tarde Thiago, Você abriu o arquivo XML de retorno? Notou que o evento não foi aceito?

O componente esta configurado para Consultar o Lote Após Envio?

Sergio, Ao alimentar o componente você não fez da forma abaixo? ICMS.SituTrib := cstICMSOutraUF; ICMS.ICMSOutraUF.CST := cst90;

Boa tarde Renato, Favor anexar o XML do evento.

Você não desenvolve em Delphi/Lazarus? Na pasta: ...\Exemplos\ACBrDFe\Schemas\Reinf temos os Schemas de todos eventos.

Boa tarde Alessandra, Com certeza 1: o provedor que atende a prefeitura de Jundiaí/SP fez alguma kaka. Com certeza 2: eles vão negar que o problema é neles e sim na sua aplicação.

Boa tarde Sergio, E como fica o XML ao setar o cst com o valor cstICMSOutraUF?

Boa tarde, Ao gerar o XML não inclua o encoding. Removi o grupo assinatura e o encoding e funcionou. S-2220-0.xml

Boa tarde a todos, Acredito que o problema seja de configuração, falta de algum arquivo XSD, ou arquivos XSD da NF-e misturados com XSD de outros tipos de Documentos Fiscais Eletrônicos tais como CT-e ou MDF-e. Pois acabo de fazer um teste, emiti uma NF-e na versão 4.00 em ambiente de homologação - SEFAZ-SP. A nota foi autorizada. Em seguida solicitei o seu cancelamento. O cancelamento foi realizado com sucesso. Não ocorreu nenhum erro de falta de schema ou outra coisa, funcionou 100%.

Boa tarde, Veja este link: http://www.ophos.com.br/app/publicacoes/detalhe/ct-e-de-subcontratacao/

Boa tarde Luiz, Infelizmente os estagiários que estabeleceram a chave dos eventos resolveram usar somente os 8 primeiros dígitos do CNPJ. A solução que vejo é você usar o ultimo campo da chave (Numero Sequencial) para determinar as filiais, não vejo outra saída a não ser essa.

Então você esta tentando validar o XML com Schema errado.

Dércio, Com certeza o provedor fez alguma kaka no ambiente de produção.

Boa tarde Valdelir, Use o programa exemplo, configure o campo SSLLib com o valor libWinCrypt e deixe o resto com os seus valores padrões. E faça os testes.

Boa tarde, Esse erro esta ocorrendo antes do envio ou é o retorno. Pois acabei de fazer um teste com o seu XML, ele foi carregado pelo programa exemplo, assinado, validado e enviado.

Boa tarde Dércio, Não, em homologação.

Boa tarde a todos, Na página 154 do Manual do CT-e versão 3.00 temos os 4 tipos de CT-e que existem (campo #17).