Leonardo Quinino

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.

Amigo qual a carteira ? é um convênio específico ? Se isso virar obrigatoriedade para as empresas, vai ter muitaaaaa gente com problemas.