Italo Giurizzato Junior

Boa tarde André, Você até pode deixar a propriedade ConsultaLoteAposEnvio com o valor True. Se o problema é lentidão, você pode configurar as propriedades: AguardarConsultaRet: se informar por exemplo 5000 o componente vai esperar 5 segundos antes de executar automaticamente o ConsultarSituacao; IntervaloTentativas: se informar por exemplo 3000 o componente vai esperar 3 segundos entre uma tentativa e outra; Tentativas: se informar por exemplo 10 o componente vai executar a consulta 10 vezes; TimeOut: se informar por exemplo 50000 o componente vai aguardar o webservice por 50 segundos antes de gerar uma mensagem de erro. Como você pode ver, as vezes podemos resolver esses problemas de tempo de resposta alterando algumas propriedades de configuração do componente.

Boa tarte Felipe, Se eu entendi direito você deseja enviar um evento de Manifestação do Destinatário informando a chave de um CT-e, é isso? Se sim, de onde você tirou essa ideia? Não existe evento de Manifestação do Destinatário para CT-e e sim somente para NF-e. Ou que você deseja fazer é enviar o evento de Prestação de Serviço em Desacordo? Se este, então por favor leia atentamente o artigo que trata sobre esse assunto clicando no link:

Bom dia André, Tanto o provedor Ginfes quando o ISSNet seguem a versão 1 do layout da ABRASF, logo porque você não usa o método ConsultarSituacao logo após o envio? O Consultar Situação vai retornar os seguintes valores: 1- Logo não enviado; 2- Lote em Processamento; 3- Lote processado com falha ; 4- Lote processado com sucesso. Se o valor do campo Situacao for 3 ou 4 devemos executar o método ConsultarLoteRps, teremos como resposta a lista de rejeições caso a situação seja 3 ou a lista de notas caso a situação for 4

Bom dia a todos, Não, temos que ter apenas um INI padrão para os dois ambientes e para todas as cidades atendidas pelo provedor. Infelizmente, tem provedor que não deveria existir, pois não conseguem manter um padrão. E sobra para nós fazer milagres. Ainda hoje vou enviar para o repositório uma alteração no arquivo INI do VersaTecnologia bem com no componente visando resolver esse problema.

Bom dia Luiz, Ainda hoje vou enviar para o repositório uma atualização do programa exemplo do componente ACBrBPe. Nessa atualização teremos um botão para exemplificar o evento de Excesso de Bagagem bem como novos campos de configuração, onde poderemos escolher se desejamos emitir o BP-e ou o BP-e TM (Bilhete de Passagem Eletrônico Transporte Metropolitano).

Bom dia, A alteração no arquivo WebISSv2.ini não se faz necessário, veja: [URL_P] RecepcaoLoteRPS=https://%NomeURL_P%.webiss.com.br/ws/nfse.asmx RecepcaoLoteRPS_3159605=https://www.webiss.com.br/%NomeURL_P%_wsnfse/NfseServices.svc [URL_H] RecepcaoLoteRPS=https://%NomeURL_H%.webiss.com.br/ws/nfse.asmx RecepcaoLoteRPS_3159605=https://www.webiss.com.br/%NomeURL_H%_wsnfse_homolog/NfseServices.svc Note que tanto para Produção quanto para homologação temos duas URLs. A maioria das cidades se utilizam da primeira que podemos dizer ser a URL padrão, a segunda é utiliza pela cidade de Santa Rita do Sapucai/MG cujo código IBGE é 3159605. Temos que comparar a URL da cidade para ser se ela se enquadra a URL padrão, caso afirmativo não precisa alterar o arquivo WebISSv2.ini apenas o Cidades.ini Quando ao tempo de resposta, devemos aumentar o valor da propriedade Timeout. Outra coisa muito importante, muitos provedores apesar de terem o ambiente de homologação, nem sempre ele funciona como deveria, infelizmente.

Boa tarde, A rejeição 375: Rejeição: NF-e com lançamento relativo a Cupom Fiscal referencia uma NFC-e [nItem: nnn] é facultativa, ou seja, cada UF poderá implementar ela ou não. O que diz a regra: NF-e (mod=55) com lançamento relativo a Cupom Fiscal (CFOP=5.929) e existe NFC-e referenciada (tag:refNFe com modelo 65) Observação: Regra de Validação opcional, a critério da UF poderá ser aceito o CFOP 5.929. (NT 2015.002) Resumindo: Rejeitar a NF-e com CFOP = 5929 que contem uma NFC-e referenciada.

Bom dia, CNPJ é uma coisa, Inscrição Estadual é outra. Uma empresa pode ter CNPJ e não ter Inscrição Estadual por exemplo.

Bom dia Eliezer, Por favor, peça para esse provedor os schemas para que possamos validar o XML antes do seu envio. Pelo que pude ver pelo XML de exemplo eles fizeram algumas alterações na estrutura do XML, portanto não é fiei a versão 2 do layout da ABRASF.

Bom dia Marcos, Você atualizou todos os fontes de todas as pastas? Reinstalou a suíte ACBr usando o ACBrInstall_Trunk2 com a opção de apagar arquivos antigos marcada? 21-env-lot.xml 21-env-lot-soap.xml 21-rec.xml 21-rec-soap.xml

Diego, Se prepara pois tem varias pegadinhas no schema da cidade de Cataguases. Realmente eu gostaria de conversar pessoalmente com o responsável (se podemos chamar de responsável) desse provedor. Os caras mudam o namespace do schema, mudam algumas tags dentro do schema, sinceramente eu não entendo.

Bom dia Mago, Tente emitir uma nota através do site, ai você compara o XML gerado pelo site com o do componente, mais precisamente as tags: "ItemListaServico" e "CodigoTributacaoMunicipio".

Bom dia Sandro, Procure sempre utilizar o programa exemplo para realizar os testes. Outra coisa a configuração esta desta forma?

Bom dia Diego, Muito obrigado pela colaboração, assim que possível vou analisar a sua alteração. Acredito ter encontrado uma forma de compatibilizar para todas as cidades desse provedor. Segue os arquivos em anexo para que vocês possam fazer os testes. Cidades.ini VersaTecnologia.ini ACBrNFSeConfiguracoes.pas

Bom dia a todos, Eu não sei o que passa na cabeça desse pessoal dos provedores. Não conseguem manter um padrão para todas as cidades atendidas por eles. Diego, favor anexar a unit que você alterou para que eu possa analisar. A alteração feita no arquivo INI acaba gerando efeito colateral em outras cidades que são atendidas pelo mesmo provedor, é preciso encontrar uma forma de resolver esse problema.

12/08/2020 Regras de validação do MDF-e Integrado - Ambiente de Homologação Comunicamos que as regras de rejeição 725 e 726 referentes ao MDF-e integrado foram reativadas SOMENTE no ambiente de HOMOLOGÇÃO de empresas da SVRS para permitir testes das empresas.

Boa tarde Sandro, Esse é o grande problema, os caras disponibilizam o schema com ID todo minúsculo e implementa no webservice com ID "Id". Se gera com "id" o XML é validado, mas ocorre outros erros como por exemplo assinatura invalida.

Boa tarde Felipe, O emitente é pessoa física ou jurídica? A principio todas as empresas (pessoas jurídicas) que emitem NF-e ou CT-e já estão liberadas para emitir MDF-e. Essa rejeição ocorre quando o emitente é uma pessoa física ou alguma kaka da SEFAZ-RS.

Bom dia Mago, Muito obrigado pelo arquivos. Procure sempre anexar os arquivos alterados, assim fica mais fácil de fazer a analise. Já inclui na minha lista de tarefas.

O XML esta correto sem acentos. O problema é que o Monitor alimenta o componente com as vogais acentuadas e depois gera o XML. O DANFE é impresso e o PDF é gerado com as informações que estão carregadas no componente.

Boa tarde Marcos, Pelo que notei esse XML não contem as vogais acentuadas.

Boa tarde Antares, A quantidade máxima de casas decimais esta estabelecido no Manual, logo o XML vai ser gerado com a quantidade máxima permitida, se for alterado o XML não é validado, não sendo validado não é enviado.

Boa tarde Mago, Quais arquivos alterou? Favor anexar para que possamos analisar.

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

Bom dia Marcos, Enviei para o repositório as alterações no componente visando a implementação do provedor AEG, favor atualizar todos os fontes de todas as pastas e inicie os testes. Muito obrigado pela colaboração.