Painel de líderes

Boa tarde a todos, Não adianta nós desenvolvedores reclamar com o provedor. Temos que pedir para os nossos clientes abrir um protocolo na prefeitura relatando todos os problemas. E esperar que a prefeitura tome alguma providencia.

Jussara boa tarde, Estamos tendo vários problemas até hoje com a emissão via ISSNet. Lentidão no processamento dos lotes é o mais frequente, tivemos casos de liberar só no dia seguinte um lote enviado as 14hs, é totalmente inviável esta situação. Tenho clientes reclamando diariamente. Entramos em contato diversas vezes e a resposta é sempre a mesma, que estão na fila de processamento e que temos que aguardar. Hoje mesmo, no meio do dia, depois de várias notas já emitidas o provedor me informa que a serie da nota é inválida, sendo que são idênticas as já emitidas, complicado! Infelizmente este provedor não esta dando conta do volume de notas da cidade de Ribeirão Preto, e tínhamos a esperança que passado o primeiro mês isso que resolveria, só que esta piorando a situação. A título de informação, temos sistemas em Delphi que utilizam Acbr e em C# de autoria da empresa, nos dois casos temos os mesmos problemas. Desculpem pessoal é mais um relato do estamos enfrentando em Ribeirão Preto com este novo provedor. Att, Júlio Ferdinando

Sim rodoviário, Então o peso final acaba sendo o peso normal, é coisinha miúda(cosméticos), as vezes nem 1kg pesa... Só que ai a emissão de cte é por nf, então acaba sendo volumosa a quantidade de informações.

Boa tarde Luís, MDF-e rodoviário? 3 mil CT-e informados no MDF-e? Se é rodoviário o caminhão tem quantas carretas?

Boa tarde. Já no svn Att.

Não tinha aberto o arquivo. O problema é na leitura do XML. Veja que no teu arquivo falta fechar a tag IPI.

Ele esta informando a pDevol do item, o que ele afirma é que o vIpiDevol esta sendo zerado, mesmo ele alimentando o campo. Nos dois xml estão iguais. Tente ZERAR a base do IPI, que esta sendo informada nos tributos, pode ser isso. Dercide.

Amigos, bom dia. Consegui descobrir o que estava fazendo de errado, na verdade como estava alterando a data de emissão, o digestvalue acabava ficando diferente do retorno da SEFAZ, e por isso não conseguia validar o xml. Caso resolvido. Obrigado a todos.

Boa noite, Verifica se a pasta de Schemas esta atualizada.

Ok, vou verificar para adicionar essas configurações...

@José M. S. Junior, acho que deveríamos incluir configurações para o TimeOut e Attempts, no ACBrMonitor e na ACBrLib

Hoje está apresentando esse erro, alguém mais está com esse problema?

http://www.ribeiraopreto.sp.gov.br/JW34/noticia/5299 Acreditamos que seja instabilidade com a ISSNET, alguns sistemas estão com o mesmo problema. Alguém de vocês conseguiram solucionar?

Boa noite, Eu também tive esse erro. O que eu fiz e pareceu funcionar, foi mudar o Result := PadLeft(Carteira, 1, '0' ) para Result := PadLeft(Carteira, 3, '0' );

Não mas tu pode pegar no exemplo e adicionar na parte da tag rodo conforme segue rodo.infANTT.infPag.New. dai preencher os dados da classe e então gerar o xml.

Bom dia Cesar, Temos um novo grupo no MDF-e chamado <infPag> que se refere as informações do pagamento do Frete, como o schema permite "N" ocorrências isso significa que esse grupo poderá aparecer mais de uma vez no XML. No meu entendimento só devemos informar esse grupo mais de uma vez quando parte do pagamento for realizado por um responsável e parte por outro. Temos também um evento para registrarmos as informações sobre o pagamento do Frete e como consta na NT, isso significa que o pagamento será realizado de forma tardia. Entendo que primeiro o transporte será realizado para depois realizar o pagamento. Quando incluímos as informações sobre o pagamento do Frete no MDF-e, isso significa que o pagamento do mesmo vai ocorrer antes do transporte. Como o NT não deixa muito claro, foram essas as minhas conclusões.

Boa tarde Cesar, Respondi a sua pergunta pelo Chat. Mas fica aqui o link da noticia sobre esse assunto.

Boa tarde, Apesar de constar na NT 2020/001 que o numero de ocorrências do grupo <infPag> é 0-1, ou seja, no máximo uma ocorrência, o correto é 0-n, portanto podemos ter "N" ocorrências referente as informações de pagamento do frete. Não existe nenhuma vinculação ao DF-e incluído no Manifesto.

Boa noite Anderson, Não é para gerar mesmo, você informou que o Tipo do Emitente é 1 = Prestador de serviço de transporte. Neste caso só vai aceitar as chaves dos CT-es. Você tem que informar 2 = Transportador de Carga Própria