RFWVO para RFW.SEFAZ

O móduluo RFW.SEFAZ oferece objetos do tipo RFWVO para utilização direta por sistemas implementados com a utilização do Página principal#RFW - ORM. O objetivo é facilitar a implementação e compartilhamento dos objetos entre multiplos sistemas.

Requisitos

• Os VOs implementados aqui seguirão a convenção de implementação do RFW Framework, permitindo que sejam persistidos e validados nos moldes do Framework.
• As definições de schema e table devem seguir um padrão que permita adaptação pelo sistema através do RFWDAO#Criando_o_DAOResolver sem a necessidade de instanceOf por questões de performance.
• Independente de oferecer uma estrutura de VOs, o módulo deve expor seus métodos de comunicação com a SEFAZ utilizando objetos diretos (criados em espelho ao XSD da SEFAZ), de forma que o sistema que não utilize os VOs ainda possa utilizar o módulo livremente para a comunicação.
• A conversão entre os VOs oferecidos pelo módulo e os objetos espelho do XML deve ser oferecido em classes utilitárias separadas, mantendo sempre o destacamento do "sistema de comunicação" e a parte de "persistência" (Cadeia de VOs).

Schema e Table dos VOs

Todos os VOs terão as seguintes definições:

• schema = "_RFW.SEFAZ" - permitindo que o RFWDAO#Criando_o_DAOResolver possa realizar a alteração da detecção dos objetos deste módulo e adaptar para o schema da aplicação sem o instanceOf de objeto por objeto;
• table = "sefaz_xxx" - onde xxx é o nome identico ao do objeto, sem o sufixo VO. É recomendado que se utilize os nomes das tabelas conforme definido neste módulo, deixando o prefixo sefaz_ exclusivo pra as tabelas deste módulo. Assim, o script de atualização do banco deste módulo pode ser usado sem adaptações/conflitos, além de não necessitar um RFWDAO#Criando_o_DAOResolver DAOResolver para o nome das tabelas.

Exemplo de Definição:

	NFeVO
	@RFWDAOAnnotation(schema = "_RFW.SEFAZ", table = "sefaz_nfe") public class NFeVO extends RFWVO { ... }

Definição dos VOs

Os nomes dados aos VOs seguirão os mesmo nomes das Tags definidas no XML da SEFAZ, tentando refletir ao máximo a própria estrutura definida pela a SEFAZ. Acredita-se que ao seguir a mesma estrutura teremos menos problemas - ou mais fácil adaptação - em relação a atualizações futuras realizadas pela SEFAZ.

• Exemplos:
  • <NFe> → NFeVO
  • <infNFe> → InfNFeVO

Convenção de Nomes e Traduções Ainda que a convenção seja de programar com nome de métodos e enums em inglês, para este módulo e valores relacionados aos documentos da SEFAZ serão aceitos que sejam batizados nomes em português para evitar a criação de dupla nomenclatura para os campos/atributos métodos e enumerations, simplificando a programação e evitando confusão e erros. No entanto, não devem ser utilizados acentos ou outros caracteres especiais nos nomes.

Objeto raiz: ProcNFeVO

Considerando que a NFe assina é distribuída a partir da tag <procNFe> e não da <NFe>, que inclusive contém os dados de autorização e assinatura, convecionamos para a persistência do documento fiscal no módulo que o objeto razis será o procNFeVO, e o relacionamento com os demais objetos será montado a partir deste.

Recomendação de Objeto Raiz do Sistema

É recomendado que o sistema tenha seu próprio objeto raiz, e que dentro dele referencie o ProcNFeVO oferecido pelo módulo. E que neste objeto do sistema os principais campos utilizados para busca ou exibição em listagens sejam "espelhados", evitando assim que buscas e listagem necessitem diversos joins no banco de dados, melhorando sua performance.

O objeto raiz do sistema pode conter os atributos serie e nNF de identificação do documento, que originalmente estão dentro no caminho ProcNFeVO.NFeVO.InfNFeVO.IdeVO. Embora se repita o valor em ambas as tabelas, esses campos utilizados comumente na listagem ou na busca evitam joins no banco de dados, além de permitirem índices mais facilmente em uma única tabela.

Recomendação de Definição:

• O nome desses atributos espelhados devem ter o mesmo nome do atributo original;
• Em caso de conflito dos nomes, como as tags <xNome> e <CNPJ> que existem tanto na tag de identificação do emissor quanto do destinatário, recomenda-se colocar como prefixo desse atributo o nome da tag pai "para desempate". Por exemplo: destXNome e emitXNome.

Atributos de Controle

Tendo um objeto raiz, o sistema também pode definir neles campos adicionais para controle como, por exemplo, um atributo status que define uma enumeção para definição do estado da NFe, como

Validação e RFWMetaAnnotations

As definições das RFWMetaAnnotations devem ser realizadas conforme a especificação do documento da SEFAZ, considerando o tipo do atributo, tamanhos máximos, casas decimais, etc.. De modo que o RFWValidator possa validar a estrutura do documento o melhor possível para enviar rejeições.

Definições de Obrigatoriedade Embora a SEFAZ defina muitos campos como obrigatórios, os VOs devem ter apenas os campos estritamente essenciais definidos como obrigatórios, para que o sistema possa persistir uma nota que ainda esteja em rascunho.

Enumerations

Os campos do XML que definem ums listagem de valores específicos devem são implementadas como enumerations na classe SEFAZEnumeration e sempre com o prefixo SEFAZ para evitar conflitos com enums do sistema, e facilitar o "auto-complete" da IDE.

Essas enumerations devem ter seus valores com nomes que reflitam a definição escificada no XML e os seguintes métodos:

• getXMLData() - que recupera o valor a ser utilizado no XML a partir da enumeration;
• valueOfXMLData(String xmlValue) - que interpreta o valor recebido no XML e retorna o valor correspondente da Enumeration.
• isDeprecated() - indicador booleano que informa se esse atributo ainda pode ser utilizado nas emissões atuais.

Atualizações e Valores Depreciados Em algumas atualizações valores deixam de existir e novos são adicionados. Nestes casos os valores das enumerations devem ter a definição da versão inicial e final em que podem ser utilizadas, para afeitos de validação. Elas não devem receber @deprecated no código, pois devem ser mantidas para compatibilidade com notas antigas do sistema (ou seja, não são Deprecated a nível do sistema, apenas de novas utilização), mas devem ser marcadas como deprecated no método isDeprecated().