Italo Giurizzato Junior

Bom dia Luiz, O que tudo indica a cidade de Farroupilha realmente mudou de Infisc para Tecnos, sendo assim se faz necessário configurar o programa exemplo para que ele utilize os schemas que estão na pasta: ...\Exemplos\ACBrDFe\ACBrNFSe\Schemas\Tecnos

Bom dia Moroni, Verificando os schemas notei que para esse provedor o valor do Id tem que ser um numero inteiro, logo isso explica o erro apresentado na sua primeira postagem onde o valor do Id é "sub13", portanto só vai validar corretamente se for apenas "13". Fiz uma alteração que acredito vai resolver o problema. Favor atualizar os fontes e faça um novo teste.

Bom dia Juliano, Muito obrigado pela colaboração, fiz a alteração e já vou enviar para o repositório.

Bom dia Fernando, Ao revisar as rotinas que geram o XML dos diversos serviços disponibilizados pelo eFrete notei divergências entre os layouts apresentados no manual (versão 6 se não me falha a memória) e os layouts apresentados pelo SoapUI. Optei por compatibilizar com o que o SoapUI apresenta, pois acredito que de outra forma o webservice vai recusar. Ajudaria em muito se o eFrete disponibiliza-se também XMLs de exemplos e um manual mais coerente.

Boa tarde a todos, Favor atualizar os fontes e fazer um novo teste usando o arquivo INI que enviei para o repositório. Wilchaia, faça uma copia da alteração que você fez na unit e utilize a que esta no repositório. Quero saber se realmente se faz necessário a alteração que você fez nessa unit. Detalhe importante sobre o provedor Futurize, apesar de constar todos os serviços ao acessar o WSDL do webservice, os métodos que realmente funcionam são: Gerar (para enviar um RPS por vez), Consultar NFS-e por RPS e Cancelar NFS-e. No arquivo INI deixei somente o Envelope dos métodos que funcionam. O dia que eles implementarem ou corrigirem os demais, basta acrescentar a definição do envelope no arquivo INI.

Bom dia a todos, No meu entendimento para esse provedor deveríamos fazer o seguinte. Ler cada informação contida dentro dos "[" "]" e colocar na lista: NFSe.Servico.ItemServico Essa lista possui os seguintes campos: Descricao, Quantidade, ValorUnitario e ValorTotal. O componente DANFSE (pelo menos para o Fortes) possui uma propriedade de configuração chamada: DetalharServico Com a lista alimentada e com essa propriedade setada com o valor True, será apresentado uma tabela aos moldes da NF-e. Acredito que vale a pena estudar mais sobre esse assunto e fazer uma alteração na rotina que lê o XML da NFS-e para que a mesma alimente a lista quando for esse provedor e outros que por ventura retornem dessa forma. Caso alguém queira arregaçar as mangas e fazer essa alteração sem que ocorra nenhum efeito colateral com os demais provedores, toda ajuda é bem vinda.

Bom dia Fernando, No meu entendimento o webservice deve ter um layout igual para ambos os ambientes (produção/homologação), caso contrario não tem como você atestar que a sua rotina esta correta. Não faz nenhum sentido você enviar um pedido de adicionar uma viagem para o ambiente de homologação com meia dúzia de informações e para o de produção tem que ter mais de uma dúzia. Veja isso: URL de ambiente de homologação: https://dev.efrete.com.br/Services/PefService.asmx?WSDL Se você procurar pela tag que esta gerando a rejeição temos a seguinte definição: <s:element name="UnidadeDeMedidaDaMercadoria" type="s1:UnidadeDeMedidaDaMercadoria"/> <s:simpleType name="UnidadeDeMedidaDaMercadoria"> <s:restriction base="s:string"> <s:enumeration value="Indefinido"/> <s:enumeration value="Tonelada"/> <s:enumeration value="Kg"/> </s:restriction> </s:simpleType> Note que essa tag aceita os seguintes valores: Indefinido, Tonelada e Kg. E você informou o valor Kg, portando não existe nenhum erro na geração do XML.

19/06/2020 [PRORROGADA] Suspensão das regras de validação da ANTT: COVID-19 Conforme resolução ANTT nº 5879/2020 o ambiente de autorização do MDF-e suspenderá as validações de cadastro do RNTRC e frota de veículos pelo prazo de 120 dias a fim de evitar rejeições indevidas nesse período de prevenção ao COVID-19. [PRORROGADA SUSPENSÃO até 08/09/2020] [PRORROGADO] Adiamento Regras de Validação da NT do MDF-e Integrado - COVID-19 Comunicamos que as regras de validação restritivas da NT 2020.001 MDF-e integrado foram adiadas para 08/09/2020 devido as dificuldades adicionais impostas pela pandemia do COVID-19. O evento de pagamento e as demais alterações de schema da NT, como são opcionais, terão sua data mantida em 06 de abril de 2020. [PRORROGADO ADIAMENTO até 08/09/2020

19/06/2020 [PRORROGADA] Suspensão Regra de Validação - COMUNICADO - COVID-19 Como forma de simplificar o procedimento dos transportadores rodoviários de passageiros, comunicamos que, de forma excepcional em função da pandemia do COVID-19, a regra de validação "Vedar cancelamento se data/hora de autorização do evento for superior à data/hora do embarque" (Rejeição 220), aplicada aos bilhetes de passagem eletrônicos - BP-e, a critério da Sefaz Autorizadora poderá ser desabilitada pelo prazo de 60 dias até o dia 08/09/2020, podendo este prazo ser prorrogado. [PRORROGADA SUSPENSÃO até 08/09/2020] Assinado: Coordenação Técnica do ENCAT

Boa tarde, Na NF-e também só existe um único lugar que gera o conteúdo da tag qrCode e esta com o caractere "!". Vasculhei várias Units para ver se achava alguma função ou procedure que estivesse removendo o caractere em questão mais não achei nada.

Bom dia, Como disse isso é muito estanho pois o conteúdo da tag é gerado pela unit pcteCTeW e nela temos: if CTe.infCTeSupl.qrCodCTe <> '' then begin Gerador.wGrupo('infCTeSupl'); Gerador.wCampo(tcStr, '#196', 'qrCodCTe', 50, 1000, 1, '<![CDATA[' + CTe.infCTeSupl.qrCodCTe + ']]>', DSC_INFQRCODCTE, False); Gerador.wGrupo('/infCTeSupl'); end; Como você pode ver consta o caractere "!", e o fragmento de código mostrado acima é executado independente do ambiente selecionado para o envio do CT-e. Será que não é o antivírus que esta removendo esse caractere?

Bom dia a todos, Temos tomar cuidado ao comparar, pois o componente gera e envia o XML do RPS, o webservice gera e retorna o XML da NFS-e. Portanto podem haver diferenças na nomenclatura de algumas tags, bem como a sua posição dentro do XML.

Bom dia, Os Schemas confronta o XML referente ao envio do lote e não o Envelopamento do mesmo. O que pode estar errado é o envelopamento que deve ter algo a mais ou a menos. Com o SoapUI da para ver como devemos gerar o Envelope de todos os serviços disponibilizados pelo provedor.

Bom dia Amauri, Você se refere a uma manual do componente ACBrNFSe? Se sim, não existe. Com relação a documentação da NFS-e, temos alguns PDFs mas isso vai depender, pois as prefeituras contratam empresas que chamamos de provedores. Tem provedor que segue a versão 1 do layout da ABRASF, outros seguem a versão 2 e outros tem o seu próprio layout. Temos um repositório chamado Tools e nele você vai encontrar toda a documentação que temos: http://svn.code.sf.net/p/acbr/code/tools/DFe/NFSe/

Bom dia Carlos, O que tudo indica foi na unit pnfsNFSeG.pas Acredito que basta inserir o provedor proDeISS na lista de provedores resolva, veja onde inserir: proDeISS, // <=== Inseri aqui proRecife, proRJ, proSimplISS: begin TagI := '<' + Prefixo3 + 'Pedido' + FNameSpaceDad + '>' + '<' + Prefixo4 + 'InfPedidoCancelamento' + FaIdentificadorCanc + '>'; TagF := '</' + Prefixo4 + 'InfPedidoCancelamento>' + '</' + Prefixo3 + 'Pedido>'; end;

Bom dia Rodrigo, O XML que é lido que resulta no erro é do RPS ou da NFSe? Você poderia anexar o XML, para que possamos analisar melhor esse problema?

Bom dia a todos, No final do texto que expõe a possibilidade de emitir um MDF-e sem informar os documentos deixa bem claro quem pode usar essa opção. "(...) o modal deve ser Rodoviário e o tipo do emitente deve ser transporte próprio (2)." Quem pode emitir o MDF-e? Uma transportadora e uma empresa que realiza o transporte de carga própria. Uma transportadora informa no MDF-e os CT-e que ela mesma emitiu, por outro lado uma empresa que transporta carga própria vai informar no MDF-e as NF-e que ela mesma emitiu. Resumindo: Uma transportadora não pode emitir um MDF-e sem informar os CT-e.

Boa tarde Robson, Por favor leia o artigo do link abaixo: Você se cadastrou no eFrete como desenvolvedor (Integrador como eFrete chama)?

Boa tarde a todos, Na NT diz que futuramente ao emitir o MDF-e o CIOT será gerado automaticamente pelo sistema MDF-e. Mas não deixou claro como isso vai funcionar e a partir de quanto. Logo, só nos resta a esperar.

Boa tarde Alexandre, A cidade foi incluída no arquivo Cidades.ini e enviada para o repositório. Obrigado por reportar dos testes. Fechando. Para novas dúvidas, criar um novo tópico.

Bom dia Giovane, No que diz respeito a salvar o XML de pedido de cancelamento bem como o seu retorno, isso já existe faz tempo. Você chegou a fazer testes com o programa exemplo do componente? Marcou as opções para que o componente salve os XMLs? O componente possui 3 propriedades de configuração chamada Salvar: 1. Configuracoes.Geral.Salvar, se True salva os arquivos de envio e de retorno, como por exemplo o pedido de cancelamento. 2. Configuracoes.WebServices.Salvar, se True faz a mesma coisa que a propriedade anterior, só com uma diferença o XML salvo é completo, ou seja, exatamente o que é enviado para o webservice e exatamente o que é retornado por ele. 3. Configuracoes.Arquivo.Salvar, se True salva os arquivos que devemos manter guardados, como por exemplo o XML do RPS, da NFS-e entre outros.

Bom dia Eric, Fiz uma alteração conforme a sua sugestão, assim que for possível favor realizar novos testes.

Bom dia Maiquel, Muito obrigado pela colaboração, já enviei para o repositório. Vamos ver se aparece alguém reclamando dessa alteração. Espero que não.