nfe / client-php Goto Github PK

Error reported here: nfe/woo-nfe#3

Currently Nfe_ServiceInvoice extends APIResource to make requests to the API.
And APIResource extends Nfe_Object to use random utility methods.
This makes the code very hard to understand, change and maintain.

The Service Invoice is not an API caller, it should use an API caller to send requests. So it should use composition.
The first task I would start would be: Refactor APIResource to be used as composition instead of inheritance.

Some reference about composition over inheritance:
https://www.thoughtworks.com/insights/blog/composition-vs-inheritance-how-choose
https://en.wikipedia.org/wiki/Composition_over_inheritance

Problema ao instalar nfe via composer no WSL.
Erro:

 [RuntimeException]   Failed to extract nfe/nfe: (1) '/usr/bin/unzip' -qq '/app/vendor/composer/tmp-3a64a9d....'   -d '/app/vendor/composer/89dd7988' 
 replace /app/vendor/composer/89dd7988/nfe-client-php-a9158fa/test/Nfe.php? [y]es, [n]o, [A]ll, [N]one, [r]ename:
    NULL
  (EOF or read error, treating as "[N]one" ...)

-- Sobre o ambiente
PHP: 7.1.33
Composer: 2.1.4
Unzip: 6.0.0

Adicionar testes do PHPUnit.

Desde a versão 2.5, que introduziu a PR #11 na master, nosso módulo que se comunica com o NFEio parou de funcionar devido à mudança no nome da principal classe.

Acho que uma mudança desse nível deveria ser introduzida com mais cautela (como opcional, configurável) ou como major (versão 3.x). Estávamos configurados para aceitar o pacote nas versões "^2.4", mas tive que alterar para fixar em "2.4" agora.

Olá!
Tentei usar o composer para instalar o nfe.io (https://github.com/nfe/client-php), no entanto, já temos instalado (via composer também) o pacote do Iugu. Inclusive nossa ideia aqui é integrar as duas ferramentas relacionando o pagamento do Iugu com a geração de notas no Nfe.io.
Porém ao fazer a instalação temos as seguintes incompatibilidades:
Warning: Ambiguous class resolution, "APIResource" was found in both "/path/vendor/nfe/nfe/lib/Nfe/APIResource.php" and "/path/vendor/iugu/iugu/lib/Iugu/APIResource.php", the first will be used.
Warning: Ambiguous class resolution, "APIChildResource" was found in both "/path/vendor/nfe/nfe/lib/Nfe/APIChildResource.php" and "/path/vendor/iugu/iugu/lib/Iugu/APIChildResource.php", the first will be used.
Warning: Ambiguous class resolution, "class_tools" was found in both "/path/vendor/nfe/nfe/lib/Nfe/Backward_Compatibility.php" and "/path/vendor/iugu/iugu/lib/Iugu/Backward_Compatibility.php", the first will be used.

Como proceder neste caso?

Obrigado!

Obrigado!

As an open source project, client-php can benefit from the Travis-ci service.

Não é possível instalar a biblioteca através do composer porque a mesma não encontra-se no Packagist.

Add Coveralls support to track testing...

@gblmarquez A livraria tem um problema que acho que poderia ser alterado, é relacionado ao #9.

Tenho um cliente que irá usar o plugin WooCommerce NFe, que usa a livraria client-php, para emissão de notas de serviços, e também irá usar o plugin Nota Fiscal Eletrônica WooCommerce para emissão de nota de produtos.

O problema é que o segundo plugin usa uma classe chamada "NFe", com a mesma nomenclatura do seu plugin, que também se chama "NFe". Essa coincidência dá conflito, não permitindo usar os dois plugins ao mesmo tempo.

As opções que sugiro são:

1. Alterar a classe de NFe para outra diferente, única (fix temporário);
2. Melhorar o plugin adicionando suporte ao PSR, relacionado ao #9.

No momento, para esse projeto estou usando a opção 1. Esse issue é apenas para chamar a atenção a esse problema. Pois outras livrarias podem usar o mesmo nome dessa classe e ter o mesmo problema, se eles não usarem namespace, claro.

Prezados, está biblioteca já possui suporte ao upload de certificados, ou tem que implementar?

add psr-1, psr-2 and psr-4 support

Issue reported here, nfe/woo-nfe#1.

There some inconsistency on file names and class names.
This file lib/Nfe/APIChildResource use camel case for both his file name and class name (APIChildResource).