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.

Boa tarde Canan, A solução é muito simples. Não deixar o usuário ficar enviando a mesma nota 200 mil vezes só porque no primeiro envio ocorreu um erro, erro este causando pela internet instável do seu cliente pão duro. Vamos a receita de bolo. Se após o envio da nota ocorrer um erro de internet, o usuário tem que realizar uma consulta com o XML da nota carregado. Porque fazer essa consulta? Muito simples, quando ocorre um erro o componente não lhe informa se o mesmo ocorreu durante o envio ou durante o retorno. Carregando a nota e realizando a consulta, se o erro foi durante o retorno, a nota já esta na SEFAZ e processada, logo com a consulta saberemos o resultado desse processamento. Se a nota foi autorizada, será retornado o protocolo de autorização, como o componente esta carregado com o XML da nota, o mesmo será atualizado, ou seja, receberá o protocolo de autorização. Desta forma podemos já imprimir o DANFE e enviar o XML mais o DANFE em PDF para o cliente. Agora se o erro ocorreu durante o envio, ao consultar teremos como retorno uma rejeição acusando que a nota não consta na Base de Dados da SEFAZ, ai sim o usuário pode enviar novamente. Com uma pequena mudança no procedimento, nunca mais você terá esse problema de Duplicidade.

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.

Vou fazer isso hoje, amanhã eu posto o log ou o resultado, vlw

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.

Entrei em contato com a PayGo que junto comigo acessamos maquina do Cliente. No sistema da PayGo foi identificado que a opção de roteamento de bandeiras estava habilitado por isso estava ocorrendo o problema de sequencia invalida do numero de solicitação, o roteamento foi desabilitado realizamos a instalação novamente e fizemos testes de venda e cancelamento junto com o Suporte da PayGo, até o momento não houve problemas no PDV

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?

A Nota Fiscal Eletrônica foi instituída através do Ajuste SINIEF 07/05, ou seja, em 2005. Infelizmente, depois de 15 anos existem pessoas que acreditam que o DANFE é a nota fiscal. O DANFE como a própria sigla deixar claro nada mais é do que um Documento Auxiliar. Se o DANFE é um Documento Auxiliar da Nota Fiscal Eletrônica, logo não é a Nota Fiscal Eletrônica da mesma forma que o Auxiliar do Chefe não é o Chefe. Simples assim.

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