SEFAZ-BA · Web viewCODIFICAÇÃO PARA USO DO HELP ON LINE 21. ... a exemplo dos relatórios da Lei 4.320/64 e LRF ... O Documento Word contendo o Help deve seguir o seguinte padrão:

MANUAL DE PADRÕES - LegadoAPLICAÇÕES

Versão 01.09.00

Salvador (BA), julho de 2017

SEFAZ-BA Secretaria da Fazenda do Estado da BahiaSGF Superintendência da Gestão FazendáriaDTI Diretoria de Tecnologia da InformaçãoGEDES Gerência de Administração de Dados e Desenvolvimento de Sistemas

Secretaria da Fazenda do Estado da Bahia 12/05/23DTI - Diretoria de Tecnologia da Informação

CONTROLE DE VERSÃOVersão Data Responsável Histórico

01.05.03 26/10/2005 Equipe AD (Padrões)

1. Alteração da sigla PRS para PRT


1. Alteração no item 8 (Formatação de Documentos) referente a mudança no cabeçalho e rodapé dos documentos.


1. Alteração no item 5. Relatórios


1. Exclusão do item 8. FORMATAÇÃO DE DOCUMENTOS

01.06.02 09/06/2009 Equipe AD(Padrões)



1. Alteração gramatical no item CONSIDERAÇÕES GERAIS


1. Inclusão do item ARQUIVOS PRÓPRIOS DE CONFIGURAÇÃO

01.08.00 01/08/2012 Equipe AD(Padrões) 1. Inclusão do item SCHEMA XML

Página - 2 document.doc


01.09.00 20/11/2015 Equipe GQS(Padrões)




RESUMO

O presente documento contempla os Padrões de Aplicações adotados na GEDES, a Gerência de Desenvolvimento e Administração de Dados da Secretaria da Fazenda do Estado da Bahia. Esse Manual abrange os padrões de objetos de programação (variáveis, constantes, tipos, ...) que devem ser utilizados para Sistemas VB como também para Sistemas e Serviços na WEB, sejam baseados no Framework ou não. Ele também contempla os padrões de Help, Relatório, Cabeçalho, enfim, de assuntos que são comuns aos ambientes de desenvolvimento adotados.

Esse Manual não visa abordar os Padrões de Interface das Aplicações. Com tal finalidade existem dois Manuais, a saber: Manual de Padrões – Interface WEB, Manual de Padrões - Interfaces Windows.

Todos os Manuais citados acima podem ser acessados através do PRT – Procedimentos de Rotinas de Tecnologia (http://prt.sefaz.ba.gov.br/).


http://prs.sefaz.ba.gov.br/


INDICE

1. CONSIDERAÇÕES GERAIS........................................................................................................5

2. NOMENCLATURA DE OBJETOS DE PROGRAMAÇÃO.....................................................5

2.1. ARQUIVOS DATA LINK.......................................................................................................52.2. CONSTANTES........................................................................................................................62.3. NAMESPACES........................................................................................................................72.4. NOMES LÓGICOS DOS OBJETOS.......................................................................................72.5. FUNÇÕES E MÉTODOS........................................................................................................92.6. TIPOS.......................................................................................................................................92.7. VARIÁVEIS..........................................................................................................................10

2.7.1. VARIÁVEIS DE FORMULÁRIOS..............................................................................112.8. VETORES OU ARRAYS......................................................................................................112.9. ARQUIVOS PRÓPRIOS DE CONFIGURAÇÃO................................................................122.10. SCHEMA XML.....................................................................................................................13

3. NOMES FÍSICOS E NOMES LÓGICOS.................................................................................14

3.1. ARQUIVOS FONTES DO VB..............................................................................................143.2. ARQUIVOS FONTES DAWEB............................................................................................153.3. ARQUIVOS DE INCLUDE..................................................................................................153.4. DLL, OCX..............................................................................................................................16

4. CABEÇALHO...............................................................................................................................17

5. RELATÓRIOS..............................................................................................................................18

6. HELP..............................................................................................................................................21

6.1. AMBIENTE WINDOWS.......................................................................................................216.1.1. CODIFICAÇÃO PARA USO DO HELP ON LINE....................................................216.1.2. ESTRUTURA DO HELP ON LINE.............................................................................23

6.2. AMBIENTE WEB.................................................................................................................266.2.1. ESTRUTURA DO HELP ON LINE.............................................................................26

7. DOWNLOAD.................................................................................................................................28



1. CONSIDERAÇÕES GERAIS

Os objetos devem ter nomes formados por uma ou poucas palavras, preferencialmente substantivos, que os identifiquem da forma mais completa possível para que possa expressar claramente o seu conteúdo, evitando a utilização de siglas e abreviações desnecessárias e também observando a cultura da organização e não apenas o contexto do sistema.

Deve-se utilizar:

nomes formados por uma ou poucas palavras( substantivos que os identifiquem);

letras minúsculas;

no singular;

tamanho máximo de 30 posições;

como conector de palavras, o caracter sublinhado ( _ ), em lugar de preposição, conjunção ou artigo;

palavras em português, salvo exceções onde não for possível encontrar uma palavra no idioma padrão que expresse claramente o conteúdo do objeto. Exemplos: software, hardware.

Não se deve utilizar :

siglas e abreviações;

acentuação ou cedilha;

formatação e caracteres especiais

2. NOMENCLATURA DE OBJETOS DE PROGRAMAÇÃO

2.1. ARQUIVOS DATA LINK

O Padrão de Nomenclatura para Arquivos Data Link que apontam para a Sede é:

Onde:

zzzzzzzz indica o nome do banco de dados (Ver Manual de Padrões - Banco)


zzzzzzzzzzzzz.udl


O Padrão de Nomenclatura para Arquivos Data Link que apontam para unidades diferentes da Sede é:

Onde:

L indica que o arquivo aponta para um banco da unidade zzzzzzzz indica o nome do banco de dados

2.2. CONSTANTES

O Padrão de Nomenclatura para Constantes é:

Onde:

B indica o escopo da Constante como segue:

G : Variável Global do Projeto L : Variável Local F : Variável do Form, Classe, Módulo(tipo Private)

vvvvvvvvvvvv indica o nome da contante

NOTA:

O Padrão de Nomenclatura para Constantes ENUM é:

Onde:




NOTA:


Lzzzzzzzzzzzzz.udl

Bcte_vvvvvvvvvvvv

Recomenda-se utilizar no máximo 20 posições para indicar o nome da constante

Benu_vvvvvvvvvvvv

As constantes elencadas na coleção enum devem seguir o padrão de nomes de CONSTANTES


Exemplo: Public Enum Genu_corcte_azul = 1cte_rosa = 2 End Enum

O Padrão de Nomenclatura das variáveis instanciadas de Constantes Enum é:

Onde:




Exemplos: Dim Fenu_cor_formulario as Genu_corDim Fenu_cor_tela as Genu_cor

2.3. NAMESPACES

O Padrão de Nomenclatura para Namespaces é:

Onde:

Nome do Projeto indica a sigla do projeto correspondente no ASA Nome do Módulo indica qual o módulo do sistema correspondente. O nome do módulo só

é necessário nos casos onde um mesmo projeto possui mais de um módulo. Nome da Classe indica o nome da classe representada no Namespace.

Exemplo: SIGAT.Arrecadacao.cls_arrecadacao

NOTA:

2.4. NOMES LÓGICOS DOS OBJETOS

Alguns objetos podem não possuir o nome lógico seguindo o mesmo padrão do nome físico . Em casos de uso de classes, por exemplo, recomenda-se que o nome lógico não seja igual ao nome físico.


Benu_nnnnnnn(variável) as enum_nnnnnnn (Constante Enum)

sigladoprojeto.nomedomodulo..nomedaclasse

O conceito de Namespace é utilizado apenas no ambiente .NET


O Padrão de Nomenclatura para o nome lógico é:

Onde:

ccc identifica o tipo do objeto ooo...ooo identifica o nome do objeto (quando estiver referenciado atributos deve ter o

mesmo nome deste) .

O tipo do objeto poderá assumir um dos seguintes códigos:

adc = Ado Data Control lbl = Labelbrk = brk broker lin = Linhacal = Calender lst = ListBoxcbr = Coolbar lsv = ListViewchk = CheckBox mnu = Menucls = classe msk = MaskEditBoxcmb = ComboBox mvw = MonthViewcmd = Command Button nod = Nodecol = Collection obj = Objetocom = ADO Command prm = ADO Parameterscon = Connection ole = Objeto OLEcre = CRPEAuto smtpclient = SMTPClientctl = Controle msg = MAPIMessagesctx = Contexto mss = MAPISessiondat = Data Control opt = OptionBoxdst = DataSet pic = Picturedbc = DbCombo prg = ProgressBardbg = DbGrid prs = PreparedStatmentdbl = DbList rcs = RecordSetdbs = DataBase rct = RichTextBoxdcb = DataCombo upd = UpDowndcn = Data Consumer rdc = Remote Data Controlden = DataEnvironment rpt = Relatório do Crystal' Reportdir = DirListBox rst = ResultSetdlg = CommonDialog shp = Shapedls = DataList stb = SSTabdrp = Data Reporter sts = StatusBardrv = DriveListBox tab = TabStripdtp = DTPicker tgr = TDBGridfgr = FlexGrid tlb = ToolBarfle = FileListBox tmr = Timerfra = Frame trv = TreeViewftp = FtpClient txt = Textgrd = Grid vis = ValueItenshfg = HierarchicalFlexGrid vit = ValueItemhsc = HscrollBar vsc = VscrollBaricb = ImageCombo xar = XArray


ccc_ooooooooooooooooooooo


img = Image wsk = WinSockiml = ImageList

NOTAS:

2.5. FUNÇÕES E MÉTODOS

O Padrão de Nomenclatura para Funções e Métodos é:

Onde:

vvvvvvvvvvvv indica o nome da Função (todos em minúsculo)NOTA:

2.6. TIPOS

O Padrão de Nomenclatura para Tipos é:

Onde:

B indica o escopo da Variável (Variáveis) tip indica o uso de um tipo nnnn é um nome livre

Exemplo: type Gtip_ficha

O Padrão de Nomenclatura para nomes das variáveis instanciadas é:

Onde:


vvvvvvvvvvvvvvvv

O nome aberto deve começar com um verbo no infinitivo impessoalExemplo: cadastrar_entidade, validar_entidade

Btip_nnnnnnnnnnnn

Btip_nnnnnn (variável) as Btip_nnnnnn (tipo)

Para classes utilizadas por mais de um projeto, deve ser utilizado o prefixo SEF, e estas devem ficar no diretório genérico de classes (Ver Manual de Padrões - Rede).

Para as classes adquiridas por terceiros e objetos comuns do VB faz-se necessária a criação de novos prefixos.


B indica o escopo da Variável (Variáveis) tip indica o uso de um tipo nnnn é um nome livre

Exemplos: Dim Ftip_ficha as Gtip_fichaDim Ftip_ficha_professor as Gtip_ficha

O Padrão de Nomenclatura para nomes das variáveis que compõem o type é:

Onde:

yyy indica o tipo do atributo definido ou tipo de objeto Windows ou outros tipos definidos vvvvvvvvvvvv indica o nome da variável

Exemplos: type Gtip_ficha (cod_pessoa as int, nom_pessoa as string,

val_pessoa as double)

NOTA:

2.7. VARIÁVEIS

O Padrão de Nomenclatura para Variáveis é:

Onde:

B indica o escopo da Variável como segue:


yyy indica o tipo do atributo definido ou tipo de objeto Windows ou outros tipos definidos.

vvvvvvvvvvvv indica o nome da variável

NOTA:


Byyy_vvvvvvvvvvvv

O escopo “G” só deve ser usado nos MÓDULOS. Para usar variáveis públicas nos forms ou classes, deve-se declará-las com o escopo “F” e utilizar as procedures GET para recuperar seu valor, e as procedures LET ou SET para alterá-lo.

yyy_vvvvvvvvv

Para referenciar o código pessoa da ficha aluno deve-se usar Ftip_ficha_aluno.cod_pessoa


A nomenclatura de variáveis de trabalho para WEB apresenta uma modificação em relação ao definido no item acima. Para maiores informações, consultar item Variáveis de Formulários.

O Padrão de Nomenclatura para Variáveis utilizadas para passagem de parâmetros é:

Onde:

P indica que é um parâmetro yyy indica o tipo do atributo definido ou tipo de objeto Windows ou outros tipos

definidos vvvvvvvvvvvv indica o nome da variável

2.7.1. VARIÁVEIS DE FORMULÁRIOS

A nomenclatura de variáveis de trabalho para WEB apresenta uma modificação em relação ao definido no item Variáveis do presente documento : o uso de letras maiúsculas, devido à utilização de um componente específico.

O Padrão de Nomenclatura para as variáveis na Web é:

Onde:

B indica o escopo da Variável como segue:G : Variável Global do Projeto L : Variável Local F : Variável do Form, Classe, Módulo(tipo Private)

yyy indica o tipo do atributo definido ou tipo de objeto Windows ou outros tipos definidos em letras maiúsculas

vvvvvvvvvvvv indica o nome da variável em letras maiúsculas

NOTA:

2.8. VETORES OU ARRAYS


Deve-se usar o escopo S para Variável Local e estática. Recomenda-se que os nomes das variáveis utilizem no máximo 20 posições livres.

Pyyy_vvvvvvvvvvvv

Byyy_vvvvvvvvvvvv

Recomenda-se que os nomes das variáveis utilizem no máximo 20 posições livres.


Não há uma definição de formato para vetores ou arrays. Sugere-se que seja adotado um prefixo que indique a semântica da informaçãoExemplo: cod para código, des para descrição.

Se o vetor ou array for composto de tipos variáveis (códigos, descrições, datas) pode-se determinar o tipo predominante e adotar o prefixo do mesmo como padrão. Exemplo: Se o vetor/array possuir mais campos do tipo data, adotar o prefixo dtc

2.9. ARQUIVOS PRÓPRIOS DE CONFIGURAÇÃO

Sempre que for necessário criar chaves específicas para executar rotinas de negócio, layout no nível do cliente, ou outras rotinas voltadas única e exclusivamente para o projeto WEB, deve-se criar um arquivo próprio de configuração:

O Padrão de Nomenclatura para os arquivos próprios de configuração é:

Onde:

yyyyy indica o nome do projeto WEB no ASA.

NOTA:

Exemplo:

No arquivo yyyyy.Config deve constar somente o trecho abaixo com as respectivas chaves do projeto:

<?xml version="1.0"?><appSettings> <add key="NOMEDACHAVE" value="VALOR" /></appSettings>

No arquivo Web.Config existe uma “TAG” chamada AppSettings e é nela que as chaves são adicionadas, conforme trecho abaixo:

<appSettings file="yyyyy.config"> <add key="NOMEDACHAVE" value="VALOR" /></appSettings>

O trecho <appSettings file=”yyyyy.config”> funciona como um “include”, ou seja, o arquivo yyyyy.config é incorporado ao web.config, juntamente com suas respectivas chaves.

Esse formato faz com que as chaves do yyyyy.config tenham prevalência sobre as chaves do web.config.


yyyyy.Config

As demais chaves devem estar no arquivo web.config.


2.10. SCHEMA XML

Sempre que for necessário criar schemas XML, deve-se seguir as orientações abaixo:

O Padrão de Nomenclatura para os arquivos de schemas XML é:

Onde:

ppp indica o prefixo conforme tabela abaixo xxxxxx é um texto livre indicando o conteúdo do esquema, caso exista mais de uma

palavra essas deverão ser separadas por “_” e não poderão ter o nome do projeto. vnn.nn indica a versão do esquema

Tabela de Prefixo:ent = Entradaret = Retornoinc = Include (Arquivos que estão incluídos em outros arquivos de esquema)

O Padrão de Nomenclatura para a tag raiz é:

Onde:

o nome da tag raiz será igual ao nome do arquivo com exceção do campo que indica o número da versão. O formato será ppp_xxxxx.

O Padrão de Nomenclatura para grupos é:

Onde: rrr indica o prefixo conforme tabela abaixo ooooo é um texto livre indicando o conteúdo do grupo, caso exista mais de uma palavra

essas deverão ser separadas por “_” e não poderão ter o nome do projeto

Tabela de Prefixo:

ent = Entradaret = Retorno


ppp_xxxxxx_vnn.nn.xsd

ppp_xxxxxx

rrr_ooooo


O Padrão de Nomenclatura para campos é utilizar o mesmo nome do atributo da tabela. Se não houver tabela, deve ser seguido o mesmo padrão de nomenclatura de atributos, conforme Manual de Padrões de Banco. Caso seja necessário diferenciar dois campos com mesmo nome, é permitido acrescentar um sufixo ao nome do campo.

3. NOMES FÍSICOS E NOMES LÓGICOS

3.1. ARQUIVOS FONTES DO VB

Os formulários (Forms), módulos e relatórios implementados no ambiente VB devem ter o nome físico(nome do arquivo) igual ao nome lógico (nome utilizado para identificá-los dentro da aplicação).

O Padrão de Nomenclatura para o nome físico dos forms, módulos e relatórios é:

Onde:

ggggg é a sigla do sistema, relativo ao código do projeto no ASA nnnnnnnnnnnnnnn é o nome do objeto

NOTA:

O Padrão de Nomenclatura para forms MDI é:

Onde:

ggggg é a sigla do sistema, relativo ao código do projeto no ASA, em letras maiúsculas. nnnnnnnnnnnnnnn é o nome do objeto

NOTA:

Não é permitido o uso de identificadores de objetos no espaço livre do formato, visto que a extensão do arquivo já o identifica.

Exemplo: mod = módulo. Formato : ggggg_mod_nnnnnnnnnnnnnnnrel = relatório. Formato : ggggg_rel_nnnnnnnnnnnnnnn


ggggg_nnnnnnnnnnnnnnn

O tamanho dos nomes dos objetos acima é livre. Os nomes devem estar separados por caracter sublinhado ( _ )

ggggg_mdi_nnnnnnnnnnnnnnn

A sigla do sistema deve estar em letras maiúsculas.


3.2. ARQUIVOS FONTES DAWEB

O Padrão de Nomenclatura para os arquivos fontes da WEB é:

Onde:

<cdTipoPagina> é um prefixo que especifica o tipo de página, com relação a sua forma de uso. Pode assumir um dos seguintes códigos:

inc = Arquivos do tipo includefra = Arquivos do tipo framesetsta = Arquivos do tipo estáticaest = Arquivos do tipo estilotpl = Arquivos do tipo template

Quando a páginas não puder ser classificadas como acima, deve-se usar o nome do assunto como prefixo, composto apenas por uma palavra sem tamanho predefinido.

Exemplos: requerer_baixa.asp, inscricao_socios.asp

<nmArquivo> indica o nome do objeto

NOTA:

3.3. ARQUIVOS DE INCLUDE

O Padrão de Nomenclatura para os arquivos de include é:

Onde:

<xxxx> indica o nome do projeto

NOTA:


<cdTipoPagina>_<nmArquivo>

Os nomes dos objetos possuem tamanho livre e devem estar separados por caracter sublinhado( _ )

<xxxxxx>.INC

Caso esse arquivo seja referenciado por mais de um projeto, usar o prefixo SEF.


3.4. DLL, OCX

O Padrão de Nomenclatura para os objetos DLL e OCX é:

Onde:

<nmLogicoProjeto> é o nome lógico do projeto e representa o campo Project Name da janela Project Properties do VB.

Nnnnn é um nome livre, que identifique aquela DLL.

Exemplo: Uma DLL do projeto DSCAD que agrupe as classes referentes a cadastro de contribuinte poderia se chamar DSCAD_insere_contribuinte.DLL

NOTA:

Cada DLL pode possuir uma ou mais classes. Sugere-se os seguintes critérios para agrupamento de classes em DLL’s:

Classes de negócio e classes de dados não podem conviver na mesma DLL Classes devem ser agrupadas de modo a formar unidades bem definidas e autônomas.

Este é um critério subjetivo onde deve-se pensar em uma abordagem que favoreça a reutilização de componentes em várias aplicações distintas. Portanto deve ser evitada a convivência de classes sem uma forte ligação semântica em uma mesma DLL


<nmLogicoProjeto><nnnn>.dll

Em caso de classes com escopo genérico (que não sejam particulares de um dado projeto)estarem agrupadas em uma única DLL, o nome desta seria composto do prefixo genérico SEF, separador underline e o restante, livre.


4. CABEÇALHO

O Padrão de Cabeçalho é:

----------------------------------------------------------------------------------------------------------------Nome: Objetivo: Data: dd/mm/aaaaAutor: Argumentos de Entrada:Retorno:----------------------------------------------------------------------------------------------------------------Histórico

Data: dd/mm/aaaa Autor: Alteração:----------------------------------------------------------------------------------------------------------------Onde:

Nome é o nome do programa Objetivo é uma descrição sucinta da(s) função(ões) que o programa desempenha. Data indica a data da criação do programa. Autor indica o Analista responsável pelo desenvolvimento do programa Argumentos de Entrada é uma listagem dos campos necessários para execução do

programa Retorno é uma Listagem dos campos resultantes do processamento do programa. ---------------------------------------------------------------------------------------------------------------- Data indica a data da alteração do programa Autor indica o Analista responsável pela alteração do programa Alteração indica uma descrição sucinta da(s) função(ões) alteradas

NOTA:


O uso desse formato para cabeçalhos


5. RELATÓRIOS

Quando não forem encontrados registros que satisfaçam os filtros especificados, deve ser exibida a mensagem “Não existem ocorrências para essa consulta”. Mesmo nesses casos, o relatório deve ser gerado. Caso o mesmo possua totalizadores, estes devem ser exibidos com “0”.

No caso dos relatórios ativados por botão de Imprimir (grid): O conteúdo de cada linha será o mesmo do grid. O relatório deverá ser formatado em colunas, sempre que possível. Se o relatório for originado por uma pesquisa com filtro, na 1ª página deverão

aparecer os valores do filtro de seleção. Caso o Gestor deseje outras informações que não façam parte do resultado da

busca, cabe ao analista identificar e especificar.

Os relatórios ativados por item de menu específico: Poderão ter uma tela associada de configuração que permita:

o Definir Filtros.o Selecionar colunas podendo, por exemplo, omitir o código de um

relatório que tem código e nome.o Definir a ordem do relatório (ex. por código ou nome).

Poderão ser abertos diretamente a partir do menu.

Para relatórios ativados por item de menu específico, após a configuração (filtros, ordem, etc) existe também um botão [Imprimir] que ativará o relatório.

Os relatórios que não precisam obedecer a normas legais devem seguir o seguinte modelo:

Governo do Estado da Bahia Emissão: dd/mm/aaaa 99:99YYY-YYYYYYYYYYYY

TTTTTTTTTTTTTTTTTTT

BBBB: bbbb

LINHA DETALHE

Total de Registros: ZZZZZZZZ

XXXXXXXX Página N de M



Cabeçalho

Fonte: Times New Roman, 12Título em negritoAlinhamento à Esquerda:

Governo do Estado da Bahia

Alinhamento à Direita:

DD/MM/AAAA 99:99 = Data e Hora de Emissão do Relatório YYY-YYYYYYYYYYY = Sigla e Nome do Sistema

Alinhamento ao Centro:

TTTTTTTTTTTTTTTT = Título do Relatório

Caso seja necessário, para atender necessidades específicas dos módulos, poderão ser incluídas informações adicionais no cabeçalho, como por exemplo:

Governo do Estado da Bahia Emissão: dd/mm/aaaa 99:99<Tipo da Administração> YYY-YYYYYYYYYYYY<Órgão> <Usuário><Unidade>

O cabeçalho deve ser exibido em todas as páginas do relatório.

Filtro

Fonte: Times New Roman, 10. Alinhamento à Esquerda:

BBBB: bbbb = Nome do campo do filtro e valor

Os critérios de filtros devem ser exibidos na primeira página, após a linha de título do relatório e antes dos dados. Caso o Gestor julgue ser necessário elaborar uma Folha de Rosto apenas para conter os filtros, essa solução pode ser adotada também. Não utilizar bordas na exibição dos filtros. A folha de rosto não conta para numeração das páginas do relatório.

Rodapé

Fonte: Times New Roman, 8.Alinhamento à Esquerda:

XXXXXXXXX é o nome que identifica o Relatório no sistema, sendo representado pelo rastro (caminho), podendo ser integral ou resumido, conforme item 5. Este item é opcional.

Alinhamento à Direita:Página N de M – N indica a página atual e M indica o total de páginas.

Linha Detalhe



Fonte: Times New Roman, recomenda-se usar tamanho 10.

Total de Registros

Este item é opcional.Fonte: Times New Roman, 10.Alinhamento à Esquerda:

Total de Registros: ZZZZZZZZ indica o número total de registros exibidos no relatório.

Legendas

Fonte: Times New Roman, 9. Alinhamento à Esquerda.O relatório poderá conter legendas, que serão exibidas na última página, após os dados.

NOTAS:Para relatórios “Legais”, a exemplo dos relatórios da Lei 4.320/64 e LRF – Lei de Responsabilidade Fiscal, o padrão deve atender a proposta do respectivo ato legal.

Nos relatórios legais de uso geral para todos os Poderes, independentemente de haver ou não padrão estabelecido em documento regulamentador, deve constar o brasão do Estado (poder executivo) já que cabe a este a responsabilidade constitucional de expedi-los.

Nos relatórios de uso geral ou específico, operacionais e gerenciais, é dispensável o uso de logomarcas.

NOTAS:


Nos relatórios do Crystal Reports, é recomendado, de forma geral, o uso de campos VARCHAR no lugar de campos TEXT. Os campos VARCHAR comportam até 8.000 caracteres, a depender dos campos das tabelas..

Relatórios do Crystal que manipulem campos TEXT com mais de 4.000 caracteres ou campos VARCHAR com mais de 255 caracteres devem utilizar DSN (ODBC) para evitar o problema do truncamento. Os demais relatórios devem continuar usando acesso nativo.


6. HELP

6.1. AMBIENTE WINDOWS

Os sistemas do ambiente Windows devem possuir o Manual de Usuário ou Help On Line. Para elaborar este último, deve-se utilizar o RoboHelp.

Em caso de uso do Help on Line, o Padrão de Nomenclatura é:

Onde:

ggggg é a sigla do sistema, relativo ao código do projeto no ASA, em letras maiúsculas. nnnnnnnnnnnnnnn indica o módulo do sistema, quando for necessário.

6.1.1. CODIFICAÇÃO PARA USO DO HELP ON LINE

Para chamar o Robohelp a partir da aplicação, é necessário manter os arquivos .hlp e .cnt no mesmo diretório do executável do sistema, e incluir o seguinte código:

' Declaração da função que executa o Help a partir do VB' Criar na seção declarations de algum módulo da aplicação

'Constantes do HELPPublic Const HELP_CONTENTS = &H3& 'primeira páginaPublic Const HELP_QUIT = &H2& 'fecha janela do helpPublic Const HELP_FINDER = 11 'conteúdo (livros)Public Const HELP_KEY = &H101& 'indicePublic Const HELP_POPUPID = &H104& 'popupPublic Const HELP_CONTEXTPOPUP = &H8& 'PopUpPublic Const HELP_CONTEXTNOFOCUS = &H108& 'Tópico FixoPublic Const HELP_CONTEXT = &H1& 'Tópico

Public Declare Function WinHelp Lib "user32" Alias "WinHelpA" _(ByVal hwnd As Long, ByVal lpHelpFile As String, _ByVal wCommand As Long, ByVal dwData As Long) As Long


ggggg_nnnnnnnnnn


NOTA:

Através da opção de Menu Ajuda, o usuário terá as informações de ajuda para o form corrente.

Para implementá-la, é necessário associar a propriedade HelpContextId do form, o número da informação desejada que se encontra na opção Topic / Properties / Advanced / Options / Map desta informação, no Robohelp. Além disso, deve-se incluir o seguinte código na aplicação:

' No menu do MDI' Quando o usuário clicar F1 dispara esse código que teste a propriedade HelpContextID do Form ativo' Se o valor da propriedade for zero, abre todo o help, senão procura o tópico correspondente

Private Sub mnu_help_Click()Dim Lcod_temp As LongIf Screen.ActiveForm.HelpContextID <> 0 Then Lcod_temp = WinHelp(hwnd, App.Path & "\shd.hlp", HELP_CONTEXT, Screen.ActiveForm.HelpContextID)Else Lcod_temp = WinHelp(hwnd, App.Path & "\shd.hlp", HELP_FINDER, CLng(1))End IfEnd Sub


Através da opção Ajuda do menu principal do sistema é possível obter as informaçõesnecessárias a sua manipulação, escolhendo as opções “Ajuda do Sistema F1” ou "Conteúdo e Índice”.


6.1.2. ESTRUTURA DO HELP ON LINE

O Help on Line deve seguir a seguinte estrutura:

CONTEÚDO

Esse tab deve sempre possuir a estrutura abaixo.

Figura 01 – Tópicos de Ajuda - Índices Ao selecionar uma dessas opções acima, Principais Funções, devem ser listadas todas as principais funcionalidades da aplicação.



Figura 02 – Tópicos de Ajuda

NOTA:


No I:\desenv\manuais\Padrões\Robohelp encontra-se um exemplo de aplicação RoboHelp, explicando o conteúdo dos tópicos apresentados.


O Documento Word contendo o Help deve seguir o seguinte padrão:

Figura 03 – Tópicos de Ajuda - Texto



ÍNDICE

Através do Índice é possível colocar palavras-chaves de acesso como forma de acesso às informações do sistema.

Figura 04 – Tópicos de Ajuda - Subitens

6.2. AMBIENTE WEB

6.2.1. ESTRUTURA DO HELP ON LINE

Assim como os sistemas do ambiente Windows, os sistemas WEB devem possuir o Manual de Usuário ou Help On Line. Para elaborar este último, deve-se utilizar o Unifw.



A estrutura do Help on Line para os Sistemas Web é a seguinte:

Página Principal

o O que há de novo?o Versão do <nome_do_sistema>o Base legal do <nome_do_sistema>o Mantém a estrutura do documento sugerido pelo SICON. É necessário acrescentar

o item Consultar Alterações de Versões Anteriores, o qual apontará para uma página contendo o Histórico das Versões.

o Obtendo Ajuda – Mantém a estrutura do documento sugerido pelo SICON.

o Visão Geral sobre o Sistema – A ordem adotada é a seguinte:

3.1. O que é o Sistema?3.2. Objetivos do Sistema3.3. Qual a base de dados do Sistema?3.4. Gestores (a subdivisão abaixo só é necessária caso existam os dois setores. Caso só exista o gestor sistêmico só é preciso ter um único tópico: 3.4.Gestor Sistêmico)

3.4.1. Sistêmico3.4.1. Setoriais

3.5. Usuários 3.5.1 Fulaninho3.5.1 Sicraninho

Convém ressaltar que:O tópico Objetivos deve conter o que hoje está descrito como Finalidade. O conteúdo hoje existente em Objetivos deve ser abordado no item 3.3 Qual a base de dados do Sistema?Os subtópicos de Usuários devem descrever cada um deles, indicando quem são e quais as respectivas responsabilidades.

o Instruções Gerais do Sistema – A ordem adotada é a seguinte:

4.1. Como acessar o sistema4.2. Senha

4.2.1. Solicitação4.2.2. Alteração4.2.3. Esqueci minha senha

4.3. Como navegar no sistema4.4. Como imprimir4.5. Funções do sistemaConvém ressaltar que:

No tópico 4.3 devem ser abordados os tópicos da Toolbar e os botões dos sistemas. No tópico Funções do Sistema deve-se relacionar as funcionalidades do mesmo.



7. DOWNLOAD

Convencionou-se que os arquivos de texto produzidos no WORD, para fins de cópia remota, devem ser veiculados pela INTERNET em formato RTF, comprimido em modo auto-executável (.EXE).


Documents

SEFAZ-BA · Web viewCODIFICAÇÃO PARA USO DO HELP ON LINE 21. ... a exemplo dos relatórios da Lei 4.320/64 e LRF ... O Documento Word contendo o Help deve seguir o seguinte padrão: