Italo Giurizzato Junior

Boa tarde Juliana, Qual arquivo esta ficando vazio? O XML do RPS bem como o de envio pelo método Gerar estão sendo gerados sem nenhum problema correto? No programa exemplo do componente temos uma opção "Salvar envelope Soap", ela esta selecionada? Se não estiver, selecione faça um novo teste e anexe os XMLs gerados.

Boa tarde Mauricí, Você esta com todos os fontes de todas as pastas atualizados? Reinstalou a suíte ACBr usando o ACBrInstall_Trunk2 com a opção de apagar arquivos antigos marcada? Se sim, para as perguntas acima, você esta usando o arquivo INI do provedor atualizado?

Boa tarde Júlio, Muito obrigado pela colaboração, fiz uma pequena alteração no arquivo Cidades.ini e SystemPro.ini que quando tivermos mais cidades talvez não seja necessário alterar o INI do provedor. Favor atualizar e fazer novos testes.

Boa tarde Gilberto, Desculpe não entendi: "Teria como, o cliente não minimizar a nota, qdo colocamos visualizar previa, o cliente não conseguir minimizar" No inicio entendo que você não quer que o cliente não minimiza a previa da nota, mas no final você diz que o cliente não conseguir minimizar. O que você quer realmente o que ocorra, que o cliente consiga minimizar ou não?

Boa tarde, No caso de um evento (cancelamento por exemplo) são gerados 3 XML. *-ped-eve.xml (solicitação ou pedido) *-eve.xml (retorno da SEFAZ referente ao evento) *-procEventoMDFe.xml (processamento final do evento, que nada mais é do que a união dos dois XMLs acima). Os XMLs *-ped-eve-soap.xml, *-eve-soap.xml não os XML exatamente como são enviados ou retornadas da SEFAZ. A mensagem de Falha que eu me recordo não é gerada pelo componente e sim retornada pela SEFAZ e ela deve constar no arquivo *-eve.xml Ao analisar os dois arquivos de pedido de evento que você anexou não encontrei nada que pudesse estar provocando esse erro. O que achei estranho é que você se refere a cancelar MDF-e, mas o arquivo de pedido de evento é de cancelamento de uma NF-e. Me explica isso melhor.

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

Bom dia Osmar, Mesmo informando com os 25 dígitos a SEFAZ rejeita o CTe OS? Então o numero esta errado. Existe a regra N038 de validação da SEFAZ ( gera a rejeição 831 ) que diz o seguinte: Se tipo de serviço = Transporte de Pessoas e informado o Número do Registro Estadual, com UF de início igual à UF do Emitente. Verificar situação do Número do Registro Estadual junto à base de dados da SEFAZ ou órgão responsável na UF autorizadora. Observação: Validar o NroRegEstadual quando informado em <rodoOS> e no grupo <prop>. Essa regra é Facultativa, isso significa que cada UF poderá implementar ela ou não. Se em SP você informa 25 dígitos iguais a 1 e funciona, com certeza a SEFAZ-SP não implementou a regra, mas poderá implementar e quando isso ocorrer vai ocorrer a rejeição. Se em MS esta gerando a rejeição, podemos concluir que a regra acima foi implementada. Para descobrir se o Numero do Registro Estadual esta corretou ou não, bem como a sua situação, entre em contato com o órgão responsável por fornecer esse numero.

Bom dia, O que se refere aos grupos de Local de Retirada e Entrega, se você notar foram acrescentados novos campos que por sinal já deveriam constar a muito tempo. Outra coisa importante os campos novos nesses grupos são opcionais, logo se não forem gerados não vão causar nenhum problema. Quanto a NT 2019/001 versão 1.00 se refere a novas regras ou alteração em regras de validação utilizadas pela SEFAZ. Vou citar como exemplo a regra B03-10 (nova) que vai fazer com que a NF-e/NFC-e seja rejeitada caso o valor de nNF seja igual a cNF ou se cNF tiver um dos valores listados na regra. Outra coisa importante no que se refere as regras de validação da SEFAZ são: a coluna Modelo que no caso da regra acima aparece 55/65, isso significa que a regra se aplica a NF-e e NFC-e; a coluna Aplic. que no caso da regra acima aparece escrito Obrig., isso significa que todas as UFs são obrigadas a implementar essa regra. Já a regra BA10-40 o Modelo é 55 e o Aplic é Facult, isso significa que essa regra só é valida para a NF-e e é facultativa, ou seja, cada UF vai decidir se vai implementar ou não. As regras dessa NT apesar de passar a valer a partir do dia 01/07/2019 (homologação) e 02/09/2019 (produção), nada impede de você vão ir fazendo os ajustes necessários na sua aplicação, como por exemplo a regra B03-10. Você pode criar uma função na sua aplicação que gere um numero aleatório com no máximo 8 dígitos, numero este que tem que ser diferente do numero da nota (atribuído a nNF) e diferente dos listados na regra. O numero gerado será armazenado no banco de dados junta mente com os demais dados da nota. Ao alimentar o componente com os dados da venda, o campo cNF conterá o numero gerado aleatoriamente pela sua função que foi salvo no banco de dados. Isso garante uma chave forte e tendo esse numero salvo no banco de dados, se for necessário gerar o XML novamente da nota, temos a garantia que a chave será gerada exatamente igual da primeira vez. Espero ter ajudado.

Boa noite Rene, Muito obrigado pela colaboração, as alterações já estão no repositório. Favor atualizar os fontes e faça novos testes usando o programa exemplo. Note que fiz alterações nos arquivos INI: Cidades.ini, Pronim.ini e Pronimv2.ini

Boa tarde Alisson, Muito obrigado pela colaboração, já enviei para o repositório.

Boa tarde Edson, Tente com essa alteração: case Fprovedor of proNotaBlu, proGiap: Result := (UpperCase(FRetornoNFSe.ListaNFSe.Sucesso) = UpperCase('true')); proISSDSF: Result := Alerta203 or (FDataRecebimento <> 0); proEgoverneISS: Result := ProcSucesso; else Result := (FDataRecebimento <> 0); end;

Boa tarde, Como eu disse antes, ao alimentar o componente com os dados do serviço é necessário informar a chave no campo ChaveNFSe. NFSe.ChaveNFSe := 'informar a chave aqui'; Se não alimentar o XML vai ser gerado sem essa informação. Para saber como gerar essa chave você deve entrar em contato com o provedor.

Breno, Muito obrigado pela colaboração, já enviei para o repositório.

Boa tarde Rodrigo, Em vez de você importar o arquivo *-gnre.xml, tente importar o arquivo *-env-lot.xml

Boa tarde Breno, Essas URLs são de Produção, correto? Se sim, e as de Homologação?

Boa tarde @Rhuan Agner, Chegou a realizar testes fora da rede da empresa? Se sim, qual foi o resultado?

Boa tarde Maxwell, A URL de homologação deve ter sido alterada, pois esta exatamente igual a que consta no manual Já a de produção tudo indica que esta correta.

Bom dia Asterix, Exatamente, o provedor já esta implementado e se faz necessário alterar o arquivo Cidades.ini E rezar para que tudo funcione. rsrsrsr

Rodrigo, O componente gera o XML conforme a versão informada em VersaoDF. No XML da versão 1.0 realmente não existe nenhuma tag ou atributo que faça referencia a versão (projeto mal feito). Já no XML da versão 2.0 a principio é para constar um atributo com a versão. Pela mensagem de erro diz que ele não encontrou a declaração do elemento TDadosGNRE, acredito que ele estava a espera do elemento TLote_GNRE, que só é gerado na montagem do lote, arquivo: *-env-lot.xml.

Bom dia Alisson, Muito obrigado pela colaboração, já enviei para o repositório.

Osmar, Segundo o Manual do CT-e versão 3.0 o NroRegEstadual tem que ter 25 dígitos.

Bom dia Rodrigo, É preciso saber como deve ser gerado o XML para ser importado pelo site. Acredito que você esteja pegando o XML do GNRe e pela mensagem de erro acho que ele esta a espera do arquivo referente ao Lote.

Bom dia Osmar, No caso do CT-e OS temos que informar o TAF ou nroRegEstadual. O TAF deve ser informado quando se tratar de transporte de pessoas interestadual e internacional e ele é obtido através do site da ANTT. O nroRegEstadual deve ser informado quando se tratar de transporte intermunicipal (dentro do estado) e ele é obtido através do Órgão Regulador de Transito do Estado ao qual a empresa esta registrada.

Bom dia Diego, Não vejo nenhuma dificuldade de incluir o ANe no ACBrMonitor, mas é preciso deixar claro que ele só funciona com a ATM.

Bom dia Carlos, Temos que tomar cuidado, pois no layout da NF-e temos duas tags: pesoL e pesoB. A primeira ocorrência dessas tags é dentro do grupo <veicProd> Grupo de Detalhamento de Veículos Novos, onde a quantidade de casas decimais são 4 e o peso tem que ser expresso em Toneladas. Esse grupo só é gerado quando a nota se refere a venda de veículo novo. Já a segunda ocorrência é dentro do grupo <vol> Grupo Volumes, onde a quantidade de casas decimais são 3 e o peso tem que ser expresso em Kg.