Leonardo Quinino

Ajuste o time timeOut do componente, isso ocorre em função da internet do emitente, poder estar lenta. em alguns casos já me ocorreu, em alguns clientes já tive que colocar 10 segundos para resolver. Segue os prints para vc entender onde ajustar.

Creio que tem que credenciar os dois, já passei por um cliente do Paraná e tivemos que fazer como citei, olhe o link o manual de credenciamento, página 2. Retirado do manual. "Vale lembrar que a Secretaria da Fazenda do Estado do Paraná – SEFA possui uma regra de credenciamento (cadastramento) de fornecedores de sistemas para emissão de documentos fiscais por processamento de dados (ver NPF 018/2001 atualizada pela NPF 081/2007). É preciso distinguir, portanto, o credenciamento (cadastramento) de fornecedores de sistemas fiscais ..."(regra para fornecedor de qualquer sistema que tenha cunho fiscal, seja para escrituração, seja para emissão de documentos) com o credenciamento (requerimento e homologação técnica) de usuários contribuintes para emissão de NF-e (regra específica de credenciamento de estabelecimento contribuinte para emissão de Nota Fiscal eletrônica). Tendo em vista a exigência que o Fisco estadual faz para controle de fornecedores de sistemas fiscais, o processo de credenciamento para NF-e deve ser necessariamente precedido do cadastramento (ou atualização de cadastro) do fornecedor de sistemas conforme regras do item 2 da NPF 018/2001 atualizada pela NPF 081/2007 para inclusão da NF-e (documento “55”) na finalidade fiscal de seu sistema" http://www.fazenda.pr.gov.br/arquivos/File/NFe/Manual_Credenciamento_NF-e_20090519.pdf

Sim, no Paraná é obrigado a SoftHouse se cadastrar para emitir NFe, lembra o método PAF, que tem que fazer um pré cadastro da SoftHouse antes de começar fazer.

Estou com problema igual. Até fiz como o colega que sugeriu colocar as DLL que o acbr usa na pasta do Lazarus, e também não resolveu. Porém no meu caso, faço a instalação do Lazarus pacote por pacote do acbr, vinha bem instalando tudo certinho e resconstruindo o Lazarus a cada pacote novo, porém quando chegou nos pacote ACBr_ANe.lpk ACBr_BPe.lpk O lazarus.exe novo chega ser criado, porém ao tentar ser executado dá erro de violação Tive que voltar o .old para poder executar novamente.

Conseguir a pegar alguma coisa , fiz todo o código, inclusive com aquele loop ao final, e salva o zip.. do XML e transforma em XML. Porém no meu teste, apareceu coisa antiga referente à habilitação do meu certificado em teste poder emitir CTe feito há uns tempos atrás. Não era exatamente uma NF-e e sim um evento de habilitação. Acho que devemos ter NF-e transmitidas contra o CNPJ do certificado. Esta é a minha difuculdade. rs Se quiser testar, eu te ajudo emitindo em HOMOLOGAÇÃO contra o SEU CNPJ e você Emite contra o MEU CNPJ.

Isso também já me ocorreu, simplesmente, sugeri duplicar o registro, gerar uma nova nota (incremento de sequencial), e deu certo. Provavelmente, foi o que foi citado, provavelmente, já ocorreu emissão com o número, e série.

Percebi esse erro de retorno, a solução que fiz foi apenas copiar os arquivos da pasta "C:\Acbr\DLLs\OpenSSL\1.0.2.13\x86" Todos os arquivos, joguei na pasta do demo e deu certo. Talvez exista solução mais "elegante" que seria jogar no Windows \system... ou syswow... (o que não gosto de fazer, pois pode ter outros aplicativos que usam a dll em outras versões).

É apenas o nome da variável, substituir CodMunicio por CodMunicipio.

Foi o que fiz.. removi os fontes. quis postar a minha solução para servir de case de ajuda para caso alguém passar novamente por essa situação.

Prezados, resolvido. Solução foi apagar a instalação anterior, e reinstalando o pacote todo novamente.

Acabei de atualizar o componente, a função GerarChaveAcesso.... passou a dar erro de compilação pcteCTeW.pas na linha, 252 com o codigo abaixo: chave := GerarChaveAcesso(CTe.ide.cUF, CTe.ide.dhEmi, CTe.emit.CNPJ, CTe.ide.serie, CTe.ide.nCT, StrToInt(TpEmisToStr(CTe.ide.tpEmis)), CTe.ide.cCT, CTe.ide.modelo); [dcc32 Error] pcteCTeW.pas(254): E2034 Too many actual parameters

Sim, consigo fazer sim tanto CTe ou CTe-OS Agora ou você desenvolve solução própria, ou contrata um serviço para fazer para você a impressão.

Existe também a opção de colocar uma marca dagua com letras gigantes.... NÃO TEM VALOR FISCAL.....

Tive um problema parecido porém com CT-e, talvez a solução seja a mesma que tive que fazer que foi aumentar o tempo de timeout... Segue um pequeno trecho de controle porém como disse para CT-e, creio que a lógica seria a mesma... ACBrCTe.configuracoes.WebServices.Tentativas := 5; ACBrCTe.configuracoes.WebServices.TimeOut := 5000; //aqui vc vai modificando conforme a situação ACBrCTe.configuracoes.WebServices.IntervaloTentativas := 500; // Intervalo entre as tentativas de envio

Obrigado, modifiquei o evento de desacordo com sequencial 1, e deu o retorno correto da SEFAZ.

Obrigado. vou revisar essa situação e deixar os sequenciais de cada evento separados.

Explicando o 180, uso para todo o sistema, um unico contador de eventos, seja carta correção, inutilização etc.. e nesse teste deu 180... Vou testar colocando um contador de eventos exclusivo essa situação e passo feedback para o fórum.

Prezados, estou tentando fazer um ajuste para evento de prestação de serviço em desacordo. Gostaria da opinião dos colegas, de onde provavelmente está o erro. Delphi XE10 - Berlin Update 2 , Pacote ACBR atualizado por SVN. Atualizei os Schemas, que estão na pasta correta, e as outras operações do sistema como transmissão de CT-e estão normais. Porém o Evento de prestação de serviço em desacordo retorna o Código 215 - Rejeição: Falha no schema XML Segue o pequeno trecho do código que estou montando. ------ MensagemErro := EmptyStr; Configurar(moCTe); try ACBrCTe.EventoCTe.Evento.Clear; ACBrCTe.EventoCTe.Evento.Add; ACBrCTe.EventoCTe.Evento[0].infevento.chCTe := ChaveCTe; ACBrCTe.EventoCTe.Evento[0].infevento.CNPJ := emitente.cnpj_cpf; ACBrCTe.EventoCTe.Evento[0].infevento.dhEvento := now; ACBrCTe.EventoCTe.Evento[0].infevento.nSeqEvento := NumeroEvento; ACBrCTe.EventoCTe.Evento[0].infevento.tpEvento := tePrestDesacordo; ACBrCTe.EventoCTe.Evento.Items[0].infevento.detEvento.infCorrecao.Add; ACBrCTe.EventoCTe.Evento.Items[0].infevento.DescricaoTipoEvento(tePrestDesacordo); ACBrCTe.EventoCTe.Evento.Items[0].infevento.detEvento.descEvento := ACBrCTe.EventoCTe.Evento.Items[0].infevento.DescricaoTipoEvento(tePrestDesacordo); ACBrCTe.EventoCTe.Evento.Items[0].infevento.detEvento.xOBS := ObsDesacordo; ACBrCTe.EnviarEvento(NumeroEvento); ACBrCTe.EventoCTe.GerarXML; CodigoStatus := ACBrCTe.EventoCTe.Evento[0].RetInfEvento.cStat; Protocolo := ACBrCTe.EventoCTe.Evento[0].RetInfEvento.nProt; DhRecbto := ACBrCTe.EventoCTe.Evento[0].RetInfEvento.dhRegEvento; XMotivo := ACBrCTe.EventoCTe.Evento[0].RetInfEvento.XMotivo; XMLFinal := ACBrCTe.EventoCTe.Evento[0].RetInfEvento.NomeArquivo; ACBrCTe.ImprimirEvento; except on E: Exception do begin if IntToStr( AcbrCte.WebServices.EnvEvento.cStat ) = EmptyStr then MensagemErro := E.Message else MensagemErro := IntToStr( AcbrCte.WebServices.EnvEvento.cStat ) + '-'+ E.Message; end; end; ------------------------- ao Fazer o EnviarEvento.... retorna a rejeição 215 - Evento de prestação de serviço em desacordo - Código 215 - Rejeição: Falha no schema XML Segue anexo, os xml gerados do evento 180-eve.xml 180-eve-soap.xml 180-ped-eve.xml 180-ped-eve-soap.xml

Na prática essa consulta CCE do RS, é muito boa, inclusive tem opção de validar se o CNPJ está habilitado para emissão de NFe.

Vou testar aqui, porém para o Entrar no projeto ACBR, uma premissa é de ser "Compilável em Lazarus". Um dos ADM podem confirmar ou não essa informação.

Aqui funcionou duas vezes e depois voltou a dar o erro. Parece que essa opção por (captcha) está instável ou será desativado.

Fica, mas sempre com pequeno atraso de 6 ou 7 minutos, (isso provavelmente é o motivo). Dificil vai ser descobrir, reportei aqui, para se no futuro ajudar algum colega.

Então... é essa a dúvida cabulosa... o windows 7 está marcado para horário de verão, porém não gerou . O que fiz conforme o colega acima citou, foi voltar 1 hora e transmitiu corretamente. Vou continuar procurando, o porque a informação gerou o xml com o fuso fora dos padrões.

ocorreu em 2 clientes, um resolveu voltando o relógio eu fiquei intrigado e não quis "resolver" para tentar sanar o problema.

Prezados, essa é para quem gosta de horário de verão, que após implementando esse ano, alguns emitentes de CT-e CT-e OS , me relataram esse tipo de rejeição: Rejeição: 212 - Data de emissao CT-e posterior a data de recebimento 24-pro-lot.xml24-pro-lot-soap.xml24-env-lot-soap.xml24-env-lot.xml32171004065234000178670010000032301406523400-cte.xml Porém, os UF de Inicio e Destino são DO ES (Espirito Santo), E HORÁRIO do corretamente ajustado, marcado como Horário de verão. Windows 7 + 64 bits em Modo de Homologação Inicialmente, achei que estaria com o horário do computador local com problemas, porém inclusive olhando o XML parece estar correto no padrão UTC inclusive o formato da data e hora de emissão. Segue os XML gerado com cteOS E O XML DE RETORNO QUE O ACBR grava . Qualquer ajuda, ficarei muito grato.