Italo Giurizzato Junior

Boa noite, Apesar de você ter configurado o Monitor para a versão 3.00 note que o CT-e foi gerado segundo a versão 2.00 Isso é porque o o Monitor ainda não esta preparado para a versão 3.00 do CT-e.

Boa noite Rogério, Faça o seguinte teste, altere o arquivo ISSFortaleza.ini de: Prefixo4=ns4: Identificador=Id para: Prefixo4=ns4: Identificador= ou seja remova o nome do identificador.

Boa noite Fábio, Favor solicitar ao provedor os novos Schemas (arquivos XSD) para que possamos analisar e se necessário criar um campo novo.

Boa noite, Na versão 3.0 do CT-e não existe mais a informação se é ou não lotação, muito menos os dados do veículo e motorista.

Boa noite, Atualize novamente.

Boa noite Felipe, Se você encerrar o MDF-e estará informando a SEFAZ que a mercadoria foi transportada e entregue, logo ficará impedido de cancelar o CT-e. Deve-se primeiro cancelar o MDF-e e depois cancelar o CT-e.

Boa tarde, Quando usamos o DistribuicaoDFe podemos ter como retorno: Resumo da NF-e -> isso indica que a nota ainda não foi manifestada. XML completo da NF-e -> isso indica que a nota já foi manifestada. Infelizmente não temos nenhum retorno indicando o tipo de manifestação. Por outro lado o emitente da NF-e, também pode usar o DistribucaoDFe, para o mesmo objetivo, com um detalhe, terá como retorno também o evento de manifestação de seu cliente. Este sim vai saber qual o tipo de manifestação realizada pelo seu cliente.

Boa noite Fernando, O campo OutrasInformacoes não existe na estrutura do RPS que o componente gera e envia para o provedor. E sim na estrutura da NFS-e que é gerado pelo provedor. Logo esse campo apesar de disponível para ser alimentado, será ignorado ao gerar o XML do RPS.

Boa noite Leonardo, Favor atualizar os fontes e testar novamente.

Boa tarde Eduardo, Favor atualizar todos os fontes de todas as pastas e refaça os testes.

Boa tarde Cleonir, Muito obrigado pelo puxão de orelha, desculpe ficou faltando acrescentar esses novos valores. Acrescentei os tipos de documentos: tdCFeSAT e tdNFCe, e o documento de transporte anterior: daBL. Favor atualizar os fontes e realizar novos testes.

Boa tarde Felipe, Ao cancelar um MDF-e, temos que informar a justificativa, esta por sua vez tem que ter um tamanho minimo de 15 caracteres e máximo de 255. Todos os Schemas estão atualizados? Favor atualizar todos os fontes de todas as pastas do ACBr, depois se utilize dos Schemas que constam na pasta: ...\Exemplos\ACBrDFe\Schemas\MDFe

Boa tarde Adailson, As informações sobre seguro esta presente somente na versão 3.00 do MDF-e. Essas informações são opcionais, mas podemos informar. Conforme consta na página 106 da Nota Técnica que traz a nova estrutura do XML, note que o grupo <Seg> pode se repetir n vezes, sendo assim você pode informar os dados dos diversos seguros caso existam mais do que UM.

Boa noite Roberto, Vou avaliar a sua implementação, assim que possível postarei um retorno.

Boa noite, Fiz a correção e enviei para o repositório. Favor atualizar os fontes e testar novamente.

Boa noite Heronim, Qual código que você se refere? Se não me falha a memória os últimos fontes que você anexou foi em novembro, e já enviei para o repositório.

Boa noite Ramalho, Favor atualizar os fontes. Fiz uma alteração visando apresentar a mensagem de erro.

Boa noite, Favor anexar o XML gerado e que não foi validado.

Boa noite, Favor atualizar os fontes e tente obter o XML completo da seguinte forma: ACBrCTe.EventoCTe.LerXML(nomeArq); sXML := ACBrCTe.EventoCTe.XML;

Boa noite Ramalho, O componente possui 3 métodos de envio, são eles: Enviar; Gerar; EnviarSincrono. Qual deles você utilizou?

Boa noite Heronim, Favor anexar os arquivos que você alterou.

Boa noite Felipe, Favor anexar também o XML de envio do evento. Uma vez que o problema é com ele e não com o XML do MDF-e.

Boa tarde Juliomar, O ACBr ao detectar que o atributo usado na assinatura for "id=", ou seja tudo em minusculo, a assinatura ocorre mas o atributo "URI=" da tag Reference fica vazia. Por outro lado se o atributo for "Id=", o seu conteúdo é repassado para "URI=" e a assinatura ocorre sem nenhum problema. Se forçar o conteúdo de "id=" ser atribuído a "URI=" ocorre erro ao realizar a assinatura. O web services de Salvador o atributo é "id=" e devemos atribuir o seu conteúdo a "URI=" caso contrario o web service rejeita o lote. Por causa de amadores contratados na implementação do web services, nós pobres mortais temos que dar os nossos pulos e implementar gambiarras. Não tenho ideia de como resolver.

Boa tarde Ramalho, Qual método você usou para enviar o RPS? Você poderia anexar um outro *-rec-soap.xml cujo o envio foi um sucesso?

Boa tarde Tatiane, O XML que você anexou encontrei espaços em branco bem como quebra de linha, isso não pode existir no XML.