[TODO-pablo-waldir] libpitangusnfe

[silvioprog]

Definir e criar biblioteca para geração de XML de NF-e.

(obs: o nome no título é sugestivo e pode ser alterado)

[pablogallardo]

Como a biblioteca gerará diversos documentos SPED, provavelmente será libpitangussped. Provavelmente este item será iniciado após #4.

[silvioprog]

Acho que libpitangussped fica muito genérico, pois SPED é todo o eco sistema de serviços eletrônicos do Estado. Definindo como libpitangusnfe fica mais específica, pois tratará especificamente de NF-e. Talvez a próxima lib a ser criada será a libpitangusesocial, especificamente para e-Social, e assim por diante. O @waldirpaim pode nos orientar melhor sobre isso.

[pablogallardo]

Em 29 de agosto de 2017 10:52:36 BRT, Silvio Clecio <notifications@github.com> escreveu:

Acho que libpitangussped fica muito genérico, pois SPED é todo o eco sistema de serviços eletrônicos do Estado. Definindo como libpitangusnfe fica mais específica, pois tratará especificamente de NF-e. Talvez a próxima lib a ser criada será a libpitangusesocial, especificamente para e-Social, e assim por diante. O @waldirpaim pode nos orientar melhor sobre isso. -- You are receiving this because you were assigned. Reply to this email directly or view it on GitHub: #5 (comment)

Silvio, Na verdade, o que estava pensando é ter realmente a libpitangussped porque logo, logo, teremos o struct SPED. Que será um struct genérico para qualquer documento SPED. Desta maneira, poderemos chamar as funções passando como parâmetro o struct SPED nas outras bibliotecas, como microsped (que poderemos chamar libpitangussefaz ou libpitangusnet ou outro nome). Exemplo: ```c send_sped(SPED *, char *url); ``` Ao invés de ter ```c send_nfe(NFE *, char *url); send_esocial(ESOCIAL *, char *url); //Demais documentos SPED.. ``` Internamente, lógico, teremos a separação que você falou: NFe, esocial, etc. Porém fazendo que a lib funcione desta maneira, podemos nos antecipar. Hoje só temos a implementação de NF-e, mas amanhã teremos outros documentos SPED e será melhor termos só uma maneira de enviar genérica de estes documentos. Pablo G. Gallardo pggllrd@gmail.com

[silvioprog]

Entendi. Não sei como você pretende gerenciar a memória dessa struct, mas posso deduzir que você usará unions. Veja, vamos supor que a struct SPED tenha 10 sub structs (NF-e, e-Social etc.), porém um usuário queira apenas a parte de NF-e para criar uma aplicação Raspberry, ou seja, naturalmente ele não poderá abusar do uso de memória, então uma struct gigante sem unions afetaria drasticamente a performance da aplicação dele. A union permitirá que ele linke apenas a struct de NF-e. Você tem algum "layout" em mente de como será essa estrutura?

[icaroraci]

Boa noite a todos. Algo que acho interessante a se levar em consideração, se tratando de gestão de memória, é que o union sempre reservará espaço para o maior elemento que possuir. Exemplo: typedef union { struct nfe_t; struct cet_t; struct esocial_t; ... }SPED; Se supormos que nfe_t é o maior dentre as opções e esocial_t o menor, nunca teremos algo menor que o tamanho de nfe_t, mesmo estanciando um objeto menor! Essa diferença pode ser sensivel, principalmente, em arquiteturas ARM. Ainda se tratando de union, é imprescindível que haja de ante mão um meio de controlar qual dos objetos de fato foi alocado em memória, porque não tem como saber o tipo do valor depois de armazená-lo. Toda essa complexidade irá diminuir ao existir structs para cada documentos eletrônico diferente. Em 29 de agosto de 2017 13:00, Silvio Clecio <notifications@github.com> escreveu:

…

Entendi. Não sei como você pretende gerenciar a memória dessa struct, mas posso deduzir que você usará unions. Veja, vamos supor que a struct SPED tenha 10 sub structs (NF-e, e-Social etc.), porém um usuário queira apenas a parte de NF-e para criar uma aplicação Raspberry, ou seja, naturalmente ele não poderá abusar do uso de memória, então uma struct gigante sem unions afetaria drasticamente a performance da aplicação dele. Você tem algum "layout" em mente de como será essa estrutura? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#5 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHpe6K3qOHkJqy7jxK1mRTQTzoJmogDsks5sdDWRgaJpZM4PEB1t> .

[silvioprog]

Caros. Há outro detalhe que não atentamos: test-case.

Eu ouvi alguns áudios do Pablo e creio que entendi um pouco o que ele pretende fazer. Seria uma espécie de estrutura abstrata para conseguir um pouco de herança. Bem, OO não é standard em C. Há a lib GLib que oferece uma estrutura que lembra OO, mas a portabilidade dela não é muito tranquila. :-/

Mas acredito que se seguirmos as standards alcançaremos bons resultados sem precisar criar estruturas muito aninhadas. Vejam um exemplo bem simples:

https://github.com/silvioprog/microsped/blob/master/exemplos/status_servico.c#L78

na linha 78 deste exemplo é criado o objeto cfg, que contém todas as definições comum (ambiente, tipo de documento, estado etc.) para a maioria das funções, daí na linha 83 ele é passado como primeiro parâmetro na função que consulta o status do serviço:

https://github.com/silvioprog/microsped/blob/master/exemplos/status_servico.c#L83

Este mesmo objeto cfg é usando também em um outro exemplo:

https://github.com/silvioprog/microsped/blob/master/exemplos/evento_cce.c#L129

e reaproveitado nesta outra chamada, passado também como primeiro parâmetro, porém na função de envio de carta de correção:

https://github.com/silvioprog/microsped/blob/master/exemplos/evento_cce.c#L138

Essa estrutura é desacoplada e 100% testável, pois cada parte pode ser testada isoladamente. E reaproveitável, mesmo sem usar qualquer variante de OO. A ideia dela foi inspirada em algumas libs Linux que seguem as standards C. Creio que podemos extrair algumas ideias de lá para criarmos estruturas "compactas" e testáveis.

[pablogallardo]

Prezados,

Bom, vou aproveitar para explicar aqui o que eu penso fazer:

Segundo os padrões de C ANSI:

C1x §6.7.2.1.13: "A pointer to a structure object, suitably converted, points to its initial member ... and vice versa. There may be unnamed padding within as structure object, but not at its beginning.")

Um ponteiro a uma struct é, na verdade, um ponteiro ao primeiro elemento. Isto é parte do padrão C e todos os compiladores que usam o padrão o respeitam.

Então hoje temos a struct NFE:

typedef struct {
	EMITENTE *emitente;
	//... outros membros
} NFE;

A Ideia seria criar a struct SPED:

typedef struct {
	char *xml;
	tipoSPED tipo;
	tAmbiente ambiente;
	//... outros membros
} SPED;

E adicionar em cada struct específico o membro SPED como primeiro membro:

typedef struct {
	SPED sped;
	EMITENTE *emitente;
	//... outros membros
} NFE;

Então, na verdade quando chamamos NFE *new_nfe() teríamos um ponteiro NFE que também pode ser usado como SPED:

NFE *nfe = new_nfe();
SPED *sped = (SPED *)nfe;
char *xml = sped->xml; //Usando o XML do SPED que foi criado como NFE

A grande vantagem de usar isso é que não teremos várias funções com o mesmo objetivo só porque trata-se de documentos SPED diferentes. E não estou falando isto só pelo envio, este foi só um exemplo. Eu estava lendo os manuais de outros documentos SPED, parece que todos tem eventos vinculáveis. Portanto, se não implementarmos deste jeito, seria terrível se organizar, teríamos que ter as funções add_evento_nfe(NFE *, EVENTO_NFE *), add_evento_esocial(ESOCIAL *, EVENTO_ESOCIAL *), etc. Com esta forma de abstração, teremos uma função só que cuida de todos os documentos da mesma maneira add_evento(SPED *, EVENTO *).

Eu tenho certeza que na implementação encontraremos mais detalhes como este. E se não começamos deste jeito, eu acho que vamos nos arrepender no futuro.

Vou responder citando algumas das respostas acima:

Toda essa complexidade irá diminuir ao existir structs para cada documentos eletrônico diferente.

@icaroraci, pelo contrário, termos structs diferentes aumentará a complexidade, e será difícil de manter. Imagina o esforço para implementar documentos SPED diferentes, sem reaproveitar nada. Estaríamos repetindo muito código.

OO não é standard em C

@silvioprog, embora C não tem orientação a objetos, podemos usar algumas coisas muito boas deste paradigma e C permite este uso, o uso do POO está presente inclusive no kernel, nas estruturas para criação de drivers.

sem precisar criar estruturas muito aninhadas.

Na verdade, não acho que as estruturas seriam aninhadas, porque assim como teremos o documento SPED, também poderemos usar cada estrutura por separado (NFE, CTE, ESOCIAL).

Espero ter explicado da melhor maneira isto. Realmente acho que esta é uma maneira bem organizada para abstrair estes documentos.