MarcosRWeimer

Veja se este server xml_rastro.xml(apaguei dados que não posso compartilhar)

Boa Tarde! Desculpe perguntar novamente, mas meu código foi aceito ou não ? Preciso mudar alguma coisa?

Encontrei uma falha ao imprimir com mais de 1 rastro (conforme MOC 7 podem ser até 500) ACBrNFeDANFEClass.pas

Boa Tarde! Conseguiram realizar a análise ? Desculpe pela pergunta, mas é que preciso atualizar o ACBr e ja aproveitaria.

Excelente colocação, como usamos os componentes em runtime não havia observado este detalhe. Anexo alteração para se adequar ao padrão atual. ACBrNFeDANFEClass.pas

Boa Tarde! Surgiu a necessidade de não imprimir o grupo de detalhamento de Rastro, verificando no código do ACBr identifiquei que teria de setar a propriedade "ImprimeDetalhamentoEspecifico" mas setar ela como FALSE implicaria em não imprimir os demais grupos (Veiculo, medicamento, arma e combustível, aqui especificamente o grupo de veículos seria um problema). Diante disso, disponibilizei uma nova propriedade: É auto explicativa, e como o padrão antes era imprimir todos, já vem por default todos marcados. Anexo fonte para análise. ACBrNFeDANFEClass.pas

Estava conversando com a Diretoria aqui, se alguém quiser abraçar a causa e receber uns trocados, passe um orçamento para implementação que a empresa estaria disposta a investir, claro, depende do valor.

problema é a parte da assinatura, é totalmente diferente, assina o cabeçalho soap, totalmente diferente das demais, tentei a pouco mais de 1 ano, mechi e muita coisa mesmo, mas a parte de assinatura do acbr conheço nada, no c# é bem mais simples esse processo de assinaturas, enfim, negocio é esperar alguem com mais conhecimentos deste recurso se empenhar. Valew!

E vocês vão implementar? Pergunto pq iria me livrar do maldito SITS... e confesso que ja tentei e não tive sucesso. Só pra exemplificar veja o que está acontecendo agora em um cliente (começaram a retornar situação = 4 ao verificar status... mas no manual não diz nada de situação 4) EDIT: Só para constar, este manual do print, acabei de baixar do site deles: https://www2.elotech.com.br/imagens/min_gra/1454429233_15.pdf

Pois é, SEFAZ poderia facilitar e não repetir os códigos de tpEvento, mas pra que facilitar né? kkk Também acho que vai acontecer de repetir mais no futuro, vai ser uma baita alteração, com certeza haverá impactos.

Uma solução para a conversão seria esta... mas não é nada elegante, o melhor a fazer, no MEU ponto de vista, seria separar o tipo enumerado (tpEvento) por documento.

Se alguem precisa resolver a parte da impressão (fast report), só alterar no DanfeEventos.fr3 procedure PageHeader1OnBeforePrint(Sender: TfrxComponent); begin if <Eventos."TipoEvento"> = '110111' then begin Memo40.Text:='CANCELAMENTO DE NF-e'; end else if <Eventos."TipoEvento"> = '110112' then begin Memo40.Text:='CANCELAMENTO POR SUBSTITUIÇÃO DE NF-e'; end else begin Memo40.Text:='CARTA DE CORREÇÃO ELETRÔNICA'; end; Memo1.Text := Memo40.Text; end;

Como está a questão do envio? Aqui estamos utilizando aquele SITS deles, mas pra ser horrível tem que melhorar muito, várias vezes não gera o arquivo de retorno e fica "preso" na pasta enviar, enfim, direto tem suporte.

A impressão do cancelamento por substituição também identifica de maneira incorreta: uma parte fica como "Encerramento" outra como "CC-e", o problema é que identifica como encerramento de MDF-e ao invés de Cancelamento por substituição.

ninguém mais identificou o problema? Ninguém verificou status da NFC-e substituída ? Até sei uma solução simples que seria no arquivo pcnRetEnvEventoNFe.pas no método TRetEventoNFe.LerXml depois da linha 193... if infEvento.tpEvento = teEncerramento then infEvento.tpEvento := teCancSubst; mas não seria "nada elegante".

Boa Tarde! Estou implementando o cancelamento por substituição, estou tendo o retorno 135 (evento vinculado e registrado) tudo conforme o esperado, porem ao verificar status retorna com status 100, então fui verificar os eventos retornados nesta consulta e encontrei um erro ao converter. TpcnTpEventoString : array[0..54] of String =('-99999', '110110', '110111', '210200', '210210', '210220', '210240', '110112', '110113', '110114', '110160', '310620', '510620', '110140', '610600', '610501', '610550', '610601', '610611', '990900', '111500', '111501', '111502', '111503', '411500', '411501', '411502', '411503', '610500', '990910', '000000', '610610', '610110', '110170', '310610', '110115', '310611', '610614', '610510', '610514', '610554', '610615', '790700', '240130', '240131', '240140', '240150', '240160', '240170', '440130', '440140', '440150', '440160', '110112', '110116'); Vejam que na terceira linha, segunda coluna (posição 7 no array), temos o '110112' e na penúltima linha, terceira coluna (posição 53 do array), também temos o '110112' Agora vejam o TpcnTpEvento: TpcnTpEvento = (teNaoMapeado, teCCe, teCancelamento, teManifDestConfirmacao, teManifDestCiencia, teManifDestDesconhecimento, teManifDestOperNaoRealizada, teEncerramento, teEPEC, teInclusaoCondutor, teMultiModal, teRegistroPassagem, teRegistroPassagemBRId, teEPECNFe, teRegistroCTe, teRegistroPassagemNFeCancelado, teRegistroPassagemNFeRFID, teCTeCancelado, teMDFeCancelado, teVistoriaSuframa, tePedProrrog1, tePedProrrog2, teCanPedProrrog1, teCanPedProrrog2, teEventoFiscoPP1, teEventoFiscoPP2, teEventoFiscoCPP1, teEventoFiscoCPP2, teRegistroPassagemNFe, teConfInternalizacao, teCTeAutorizado, teMDFeAutorizado, tePrestDesacordo, teGTV, teMDFeAutorizado2, teNaoEmbarque, teMDFeCancelado2,teMDFeAutorizadoComCTe, teRegPasNfeProMDFe, teRegPasNfeProMDFeCte, teRegPasAutMDFeComCte, teCancelamentoMDFeAutComCTe, teAverbacaoExportacao, teAutCteComplementar, teCancCteComplementar,teCTeSubstituicao,teCTeAnulacao,teLiberacaoEPEC,teLiberacaoPrazoCanc, teAutorizadoRedespacho,teautorizadoRedespIntermed,teAutorizadoSubcontratacao, teautorizadoServMultimodal, teCancSubst, teAlteracaoPoltrona); A posição 7 é teEncerramento, e é assim que o ACBr identifica o retorno da verificação de status, fica como Encerramento ao invés de teCancSubst. É identificado pela linha 193 (infEvento.tpEvento := StrToTpEvento(ok,Leitor.rCampo(tcStr, 'tpEvento'));) do arquivo pcnRetEnvEventoNFe no método TRetEventoNFe.LerXml O objetivo é setar a NFC-e como cancelada (cStat 101) mas pelo geito não vou conseguir fazer isso, já que no evento retorna 135 e no status 100. Estou testando no Sefaz/PR. Alguem de outra UF tem o mesmo problema (retornar 100 ao invés do 101 depois de autorizado o cancelamento por substituição). ?? P.S. Procurei na NT mas não encontrei nenhuma alteração na verificação de status.

Bom dia! A princípio as alterações serão estas anexas, o setor de testes aqui da empresa vai passar um parecer, o que vai demorar alguns dias, estou postando para uma avaliação prévia. pnfsNFSeW_Equiplano.pas pnfsNFSeR.pas ACBrNFSeWebServices.pas

Então, corrigi uma falha ao ler a data de emissão e data de emissão do rps no LerRPS_Equiplano, até ai tudo certo, problema que depois de ConsultarNFSeporRps estes dados são perdidos, fica apenas os 5 campos (citados uns posts acima) os demais são "limpos", não estou encontrando onde está limpando.

Só para registrar, não abandonei (ainda), estou tentando mas sem sucesso.

ok, vou implementar e quando terminar disponibilizo para avaliação Obrigado

Certo, e neste caso vc acha que o melhor lugar é neste mesmo que falei (procedure TNFSeW_Equiplano.GerarXML_Equiplano;) ?? Pergunto por que no inicio da unit tem a seguinte mensagem: {==============================================================================} { Essa unit tem por finalidade exclusiva de gerar o XML do RPS segundo o } { layout do Equiplano. } { Sendo assim só será criado uma nova unit para um novo layout. } {==============================================================================} por isso a dúvida, conheço pouco o componente, e não sei como funciona para os demais provedores.

Então, equiplano estamos implementando agora com o ACBr, temos um app em c# que gera o xml da forma citada acima, o retorno da prefeitura é aquele mesmo (dos 5 itens), o app que montava o XML com os dados da NFS-e e da autorização. EDIT: Complementando, o que preciso é do XML completo autorizado para mandar para o cliente e para carregar no ACBrNFSe e imprimir.

Boa tarde! Somente estas 5 tags, até pensei em fazer o seguinte, na procedure TNFSeW_Equiplano.GerarXML_Equiplano, verificar se possui NFSe.Numero e ai gerar o bloco "CompNFSe".. mais ou menos assim: procedure TNFSeW_Equiplano.GerarXML_Equiplano; begin //se tem a NFS-e, gera ela ao invés do RPS if (StrToIntDef(NFSe.Numero, 0) > 0) then begin //manual abrasf v2.03 Gerador.wGrupoNFSe('Nfse'); //Nfse tcNfse 1-1 Gerador.wGrupoNFSe('InfNfse'); //InfNfse tcInfNfse 1-1 //Id tsIdTag Identificador da TAG a ser assinada Gerador.wCampoNFSe(tcInt, '', 'Numero', 01, 15, 1, OnlyNumber(NFSe.Numero)); //Numero tsNumeroNfse 1-1 Gerador.wCampoNFSe(tcStr, '', 'CodigoVerificacao', 01, 32, 1, NFSe.CodigoVerificacao); //CodigoVerificacao tsCodigoVerificacao 1-1 Gerador.wCampoNFSe(tcDatHor, '', 'DataEmissao', 01, 19, 1, NFSe.DataEmissao); //DataEmissao Datetime 1-1 Gerador.wCampoNFSe(tcInt, '', 'NfseSubstituida', 01, 15, 0, OnlyNumber(NFSe.NfseSubstituida)); //NfseSubstituida tsNumeroNfse 0-1 ..... end else //se não é a NFS-e, gera o RPS (como fazia antes desta alteração) begin Gerador.wGrupoNFSe('rps'); GerarIdentificacaoRPS; GerarTomador; GerarListaServicos; GerarValoresServico; Gerador.wGrupoNFSe('/rps'); end; O que acha desta possibilidade? Tem alguma sugestão melhor?

Ola Italo O resultado foi o que eu já esperava, só mudou o "grupo":

Ola! Ninguem? Se deixar marcado para o ACBr salvar os XMLs também não funciona, vejam como ficou o xml que é para ser o da NFS-e: