NFeDistribuicaoDFe

[Chrystian Toigo]

Olá Pessoal tudo bem?

Tem alguém conseguindo usar o NFeDistribuicaoDFe?

Pois eu estou tentando usar e está dando o seguinte erro:

400Bad Request

Alguém saberia dizer porque?

Att,

Chrystian Toigo Diretor de TI cto...@gmail.com +55 (45) 9801-1007

		redes sociais:

[Roberto Machado]

Sim, sem problemas

este é um exemplo de uso (veja app/DFe.php e cron/distdfe.php)

https://github.com/robmachado/teste

Roberto

[Chrystian Toigo]

Olá Roberto tudo bem?

Baixei os testes que vc mandou, mas ainda assim continua com o erro 400 Bad Request, saberia dizer porque ocorre esse erro com o DFe?

Abs,

Chrystian Toigo Diretor de TI cto...@gmail.com +55 (45) 9801-1007

		redes sociais:

--
--
Você recebeu esta mensagem porque está inscrito no Grupo "NFePHP".
Para Postar: nfe...@googlegroups.com
Para Sair do Grupo: nfephp+un...@googlegroups.com
Link: http://groups.google.com.br/group/nfephp?hl=pt-BR
-------
Repositório: https://github.com/nfephp-org/nfephp
---
Você recebeu essa mensagem porque está inscrito no grupo "NFePHP" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para nfephp+un...@googlegroups.com.
Para mais opções, acesse https://groups.google.com/d/optout.

[Roberto Machado]

Bom estou usando nesse momento sem problemas ... não sei o que você está fazendo ai ... 

Bad request pode ser causado pode várias coisas, veja se seus arquivos estão atualizados principalmente 

config/nfe_ws3_mod55.xml 

Use o exemplo do repositório https://github.com/nfephp-org/nfephp/blob/develop/exemplos/NFe/4.00testaDistDFe.php

e veja o soapDebug ....

Roberto

[Chrystian Toigo]

Roberto, valeu muito obrigado.

Funcionou, era erro de formatação do XML para envio.

Obrigado.

Chrystian Toigo Diretor de TI cto...@gmail.com +55 (45) 9801-1007

		redes sociais:

[luiz martins]

Ola bom dia   vi que vc conseguiu fazer, mais informar uma coisa antes vinha a situação da Nfe se ja esta Manifestada ou não, o campo era cSitConf  e vinha uma destas opção 0=Sem manifestação do destinatário;1=Confirmada Operação; 2=Desconhecida;3= Operação não Realizada; 4=Ciencia .

Saberia em informa qual seria este campo nesta versa atual ?

[Roberto Machado]

Prezado;

Novo webservice, novo método e isso não tem nesse webservice

Por favor consulte Nota Técnica 2014/002 Web Service de Distribuição de DF-e de Interesse dos Atores da NF-e (PF ou PJ)

Roberto

[Fábio Ananias]

Bom dia a todos, e bom dia Roberto (um bom dia especial para o Roberto porque ele É O CARA da NF-e né... =D ),

Aproveitando o assunto da DF-e,
estou "bolando" uma sugestão de alteração da classe que gostaria de discutir com vocês,

até mesmo para ver se alguém já tem uma solução implementada.

Tanto para a DF-e quanto para a Manifestação do destinatário as notas técnicas citam logo nas primeiras páginas que o acesso às informações da DF-e ou a Manifestação poderão ser realizadas utilizando um certificado com o CNPJ base da empresa (8 primeiros dígitos).
(Nota Técnica 2014/002 Web Service de Distribuição de DF-e Pag.4).
(Nota Técnica 2012/002 Web Service de Manifestação do Destinatário Pag.3).

Isso me interessou, pois trabalho com empresas de serviços que tem várias filiais e apenas um certificado (pelo menos em meu sistema há apenas 1).

Utilizo as classes de Develop, e também o App\DF-e.php do Roberto. Dando uma força ao que o Roberto sempre diz: Tudo está perfeitamente funcional.

Fiz alguns testes para baixar os documentos de um CNPJ de uma filial utilizando o certificado com o CNPJ da Matriz (Base), e deu tudo certo.

Para realizar o teste, lá em Common/Certificate/Pkcs12.php , no método loadPfxFile, alterei 'manualmente' o padrão do parâmetro $ignoreOwner de false para true(isso apenas para testar mais rápidamente):
public function loadPfxFile( $pathPfx = '', $password = '', $createFiles = true, $ignoreValidity = false, $ignoreOwner = true ) { ... }

Bom... agora com o teste feito e com a confirmação de que funciona, minha ideia é tornar este $ignoreOwner 'dinâmico'.

Por mim, eu removeria o parâmetro $ignoreOwner do método e o tornaria um atributo da Classe, com o padrão false e com um método setIgnoreOwner().

Desta forma, nos apps de Manifestação e de DF-e eu o setaria como true.

Mas, pensando bem, não sei se é interessante apenas ignorar o "Owner" neste caso.

Então, se adicionássemos um atributo "do tipo" $verifyBaseOwner a classe seria mais interessante, já que não quero que a verificação seja totalmente ignorada, mas sim que ela verifique apenas a Base.

Em loadFfx colocaríamos uma verificação adicional a "if (!$ignoreOwner) {}" e aí a compatibilidade é mantida.

Eu quis discutir antes de sugerir alguma alteração no Git pois pode ser que alguém utilize a classe Pkcs12.php para alguma outra coisa, e precise dos parâmetros como estão.

No NFePHP utilizamos estes métodos apenas com 2 parâmetros, nos seguintes pontos:

Em Common/Base/BaseTools.php no método atualizaCertificado:
$this->oCertificate->loadPfxFile($certpfx, $senha);
$this->oCertificate->loadPfx($certpfx, $senha);

Acho que escrevi demais..

Mas também acho que ficaram claras as minhas preocupações e a minha necessidade.

Alguma sugestão?

Obrigado a todos.

[Roberto Machado]

Fabio;

Li com muita atenção o que você colocou e não vejo nenhum problema em implementarmos isso que você falou tanto com o setIgnoreOwner como o setBaseOwner

Podemos deixar apenas o método setBaseOwner(true|false) e modificar a verificação em si  

Se var $verifyOnlyBaseOwner == true  => verifica apenas os primeiros 8 digitos do CNPJ

Se var $verifyOnlyBaseOwner == false  => verifica todo o CNPJ

Roberto

[Fábio Ananias]

Obrigado Roberto. Vou alterar e subo la no Git.

--