Aumentar o tamanho de uma Região no APEX

E ai galera!!!

Novidades... estou de volta!!! E com novas dicas... agora vamos falar também de APEX, BI-Publisher e XML-Publisher....

Vou começar com uma dica da minha ferramenta favorita, dica de APEX!!!

Muitas vezes criamos regiões em nossa tela e fica feio por causa do tamanho, uma região fica grande e a outra pequena, com essa dica deixaremos as duas regiões com o mesmo tamanho.

Colocando o comando abaixo no campo "Region Attributes" das regiões, deixa elas com um tamanho de 60% da tela.

width="60%"

Se colocar 100% a região ficara com o tamanho da tela inteira.

Em breve mais dicas...

Abraços,

Query com colunas Acumuladas

Ola pessoal!!!

Desculpa pela demora em postar mais dicas, estava muito enrolado mês passado (por aquele motivo) e ainda tive uma mini-ferias... Vou tentar voltar a postar as dicas com mais freqüência agora...

Bom, vou dar um dia de query acumulado... por exemplo: Quero que o resultado de minha query seja o numero da nota, data emissão, o valor da nota, o acumulado da nota por dia e o acumulado geral, o resultado tem ser algo parecido com:

Para montar esse resultado, vou usar o comando OVER!!! Ficara assim:

Apesar da query não ter ficado alinhada (fui obrigado a colocar como figura), acho que da pra entender... não sei porque não fica alinhado do jeito que monto, isso ta limitando um monte de dicas que quero passar, com tem trechos de código maiores fica muito ruim de entender quando não esta alinhando...

Abs,

Trabalhando com Idiomas no Oracle

Olá Galera, depois de um tempinho trabalhando igual um cavalo... consegui um tempinho para postar uma nova dica.

Vamos falar de idioma!!!

Como podem ver na figura abaixo, o idioma do default do banco esta em inglês. O mês esta trazendo 'AUG', se estivesse o idioma em português traria 'AGO'.


Mas se eu quiser ver o mês em português, como que faço?

É bem simples, apenas precisamos alterar a sessão para o idioma português:


O Oracle tem uma vasta lista de idioma, faça um teste altera a sessão e veja como fica o nome do mês no idioma que quiser (lembrando que isso dependente se os idiomas estão instalados na base e que alguns idiomas têm caracteres especiais).

Olha como fica escrito JULHO em alemão:

Quando estamos com um idioma setado e passamos uma data em outro idioma da erro, mas podemos alterar o idioma de uma data no momento da execução e ainda sem mexer com o idioma da sessão,

No caso abaixo o idioma esta setado em inglês e vou passar uma data em português, vai dar erro!


Agora vou passar a mesma data, mas setando o idioma banco vai entender como uma data valida e não irá mexer no idioma da sessão.


Pra dica ficar completa abaixo tem uma lista de idiomas:

NLS_LANGUAGE = ENGLISH

us AMERICAN
ar ARABIC

bn BENGALI
ptb BRAZILIAN PORTUGUESE
bg BULGARIAN

frc CANADIAN FRENCH
ca CATALAN
zhs SIMPLIFIED CHINESE
hr CROATIAN
cs CZECH

dk DANISH
nl DUTCH

eg EGYPTIAN
gb ENGLISH
et ESTONIAN

sf FINNISH
f FRENCH

din GERMAN DIN
d GERMAN
el GREEK

iw HEBREW
hu HUNGARIAN

is ICELANDIC
in INDONESIAN
i ITALIAN

ja JAPANESE

ko KOREAN

esa LATIN AMERICAN SPANISH
lv LATVIAN
lt LITHUANIAN

ms MALAY
esm MEXICAN SPANISH

n NORWEGIAN

pl POLISH
pt PORTUGUESE

ro ROMANIAN
ru RUSSIAN

sk SLOVAK
sl SLOVENIAN
e SPANISH
s SWEDISH

th THAI
zht TRADITIONAL CHINESE
tr TURKISH

uk UKRAINIAN

vn VIETNAMESE



Abs

Tabelas Temporárias

E ai galera!!!! Beleza???

Utilizem o comando abaixo para criarem tabelas temporárias, ou seja, tabelas para manterem dados de cálculos ou para seleção e que depois podem ser excluídos.

Esse comando já define a tabela como temporária e seus dados são excluídos automaticamente após encerrar a sessão ou a transação.

CREATE GLOBAL TEMPORARY
TABLE nome_tabela ( definicao_campos....)
ON COMMIT DELETE ROWS -- exclui registros ao término da transação
-- ou
ON COMMIT PRESERVE ROWS -- exclui registros ao término da sessão

Vantagens das tabelas temporárias:
* São bem mais rápidas, pois não geram redo-logs e uma série de outras coisas.
* Os dados são vistos apenas pela sessão que inseriu os dados. Exemplo: Se alguém inserir dados dentro dela e comitar,ninguém vai ver o que tem na tabela, apenas será visto pela sessão que inseriu os dados. (cada sessão só enxerga o que é seu).
* Você não precisa se preocupar em apagar as informações, assim que a sessão ou transação (depende de como for criada a tabela temporária) terminar as informações da tabela se apagam automaticamente.


Colaboração Thiago Esmerine (Tripa).


Flw pessoal!!!

Estornar Lançamento Contábil do GL usando PL/SQL

E ai galera, belezeria???

Depois um tempo sem postar nada, estou de volta!!! Hoje vou dar uma dica sobre como fazer um estorno de um lançamento contábil do GL vai PL/SQL.

Em primeiro lugar temos que atualizar o ACCRUAL_REV_FLAG da GL_JE_HEADERS, para fazer isso estou usando uma API conforme abaixo

gl_je_headers_pkg.update_row( x_rowid => l_rowid -- ROWID da linha a ser atualizada
, x_je_header_id => r_gl_je_headers.je_header_id
, x_last_update_date => r_gl_je_headers.last_update_date
, x_last_updated_by => r_gl_je_headers.last_updated_by
, x_ledger_id => r_gl_je_headers.ledger_id
, x_je_category => r_gl_je_headers.je_category
, x_je_source => r_gl_je_headers.je_source
, x_period_name => r_gl_je_headers.period_name
, x_name => r_gl_je_headers.NAME
, x_currency_code => r_gl_je_headers.currency_code
, x_status => r_gl_je_headers.status
, x_date_created => r_gl_je_headers.date_created
, x_accrual_rev_flag => 'Y' --Flag que atualiza os dados para Y confirmando o estorno
, x_multi_bal_seg_flag => r_gl_je_headers.multi_bal_seg_flag
, x_actual_flag => r_gl_je_headers.actual_flag
, x_default_effective_date => r_gl_je_headers.default_effective_date
, x_conversion_flag => r_gl_je_headers.conversion_flag
, x_last_update_login => r_gl_je_headers.last_update_login
, x_encumbrance_type_id => r_gl_je_headers.encumbrance_type_id
, x_budget_version_id => r_gl_je_headers.budget_version_id
, x_balanced_je_flag => r_gl_je_headers.balanced_je_flag
, x_balancing_segment_value => r_gl_je_headers.balancing_segment_value
, x_je_batch_id => r_gl_je_headers.je_batch_id
, x_from_recurring_header_id => r_gl_je_headers.from_recurring_header_id
, x_unique_date => r_gl_je_headers.unique_date
, x_earliest_postable_date => r_gl_je_headers.earliest_postable_date
, x_posted_date => r_gl_je_headers.posted_date
, x_accrual_rev_effective_date => r_gl_je_headers.accrual_rev_effective_date
, x_accrual_rev_period_name => r_gl_je_headers.period_name
, x_accrual_rev_status => r_gl_je_headers.accrual_rev_status
, x_accrual_rev_je_header_id => r_gl_je_headers.accrual_rev_je_header_id
, x_accrual_rev_change_sign_flag => r_gl_je_headers.accrual_rev_change_sign_flag
, x_description => r_gl_je_headers.description
, x_tax_status_code => r_gl_je_headers.tax_status_code
, x_control_total => r_gl_je_headers.control_total
, x_running_total_dr => r_gl_je_headers.running_total_dr
, x_running_total_cr => r_gl_je_headers.running_total_cr
, x_running_total_accounted_dr => r_gl_je_headers.running_total_accounted_dr
, x_running_total_accounted_cr => r_gl_je_headers.running_total_accounted_cr
, x_currency_conversion_rate => r_gl_je_headers.currency_conversion_rate
, x_currency_conversion_type => r_gl_je_headers.currency_conversion_type
, x_currency_conversion_date => r_gl_je_headers.currency_conversion_date
, x_external_reference => r_gl_je_headers.external_reference
, x_attribute1 => r_gl_je_headers.attribute1
, x_attribute2 => r_gl_je_headers.attribute2
, x_attribute3 => r_gl_je_headers.attribute3
, x_attribute4 => r_gl_je_headers.attribute4
, x_attribute5 => r_gl_je_headers.attribute5
, x_attribute6 => r_gl_je_headers.attribute6
, x_attribute7 => r_gl_je_headers.attribute7
, x_attribute8 => r_gl_je_headers.attribute8
, x_attribute9 => r_gl_je_headers.attribute9
, x_attribute10 => r_gl_je_headers.attribute10
, x_context => r_gl_je_headers.CONTEXT
, x_ussgl_transaction_code => r_gl_je_headers.ussgl_transaction_code
, x_context2 => r_gl_je_headers.context2
, x_doc_sequence_id => r_gl_je_headers.doc_sequence_id
, x_doc_sequence_value => r_gl_je_headers.doc_sequence_value
);

COMMIT; --Commit no processamento da API que atualiza os dados do cabeçalho dos lançamentos contábeis

Depois da atualização pego o IMPLICIT_ACCESS_SET_ID do livro contábil, esse valor será usado como parâmetro para submeter o concurrent de estorno.

SELECT implicit_access_set_id
INTO l_implicit_access_set_id
FROM gl_ledgers
WHERE ledger_id = r_gl_je_headers.ledger_id;

O próximo e ultimo passo seria chamar o concurrent que estorna os lançamentos (GLPREV) passando como parametros o IMPLICIT_ACCESS_SET_ID e o ID do lote (JE_HEADER_ID da GL_JE_HEADERS).


l_n_request_id := fnd_request.submit_request( application => 'SQLGL'
, program => 'GLPREV'
, description => 'Estornar Lancamentos'
, argument1 => l_implicit_access_set_id
, argument2 => r_gl_je_headers.je_header_id
);

COMMIT; --Commit no processamento do Concorrente


Bom, aqui isso ta funcionando... os lançamentos estão sendo estornados.


Absss

Comandos básicos de banco e EBS

Uma dica rápida hoje... vou passar alguns comandos básicos de banco e EBS...

-> FND_PROFILE.VALUE('USER_ID')
-- Recupera o ID do usuário logado no EBS (USER_ID da FND_USER)

-> FND_PROFILE.VALUE('USERNAME')
-- Recupera o nome do usuário logado no EBS (USER_NAME da FND_USER)

-> FND_GLOBAL.CONC_REQUEST_ID ou FND_PROFILE.VALUE('REQUEST_ID')
-- Recupera o ID do concurrent em execução (REQUEST_ID da FND_CONCURRENT_REQUESTS)

-> FND_GLOBAL.CONC_PROGRAM_ID
-- Recupera o ID do programa em execução (CONCURRENT_PROGRAM_ID da FND_CONCURRENT_PROGRAMS)

-> FND_GLOBAL.PROG_APPL_ID
-- Recupera o ID da aplicação do concurrent em execução (APPLICATION_ID da FND_CONCURRENT_PROGRAMS)

-> FND_PROFILE.VALUE('ORG_ID')
-- Recupera o ID da Organização setada da responsabilidade corrente

-> FND_GLOBAL.RESP_NAME;
-- Recupera o nome da responsabilidade corrente

-> FND_CLIENT_INFO.SET_ORG_CONTEXT('1')
-- Seta organização no banco (por sessão)

-> DBMS_SESSION.SET_NLS('NLS_LANGUAGE', '"BRAZILIAN PORTUGUESE"') ou DBMS_SESSION.SET_NLS('NLS_LANGUAGE', 'AMERICAN')
-- Seta o idioma no banco (por sessão)

-> DBMS_SESSION.SET_NLS('NLS_TERRITORY', 'BRAZIL') ou DBMS_SESSION.SET_NLS('NLS_TERRITORY', 'AMERICA')
-- Seta o território no banco (por sessão)

-> FND_PROFILE.PUT('GL_SET_OF_BKS_ID', 1111);
-- Seta valores numa profile (GL_SET_OF_BKS_ID é profile e o 1111 é o valor que esta sendo setado)

-> DBMS_UTILITY.COMPILE_SCHEMA('<>');
-- Compila um schema inteiro

-> SELECT * FROM V$INSTANCE
-- Para pegar informações sobre o banco que esta conectado

-> ALTER USER <> IDENTIFIED BY <>
-- Para alterar a senha de um usuário de banco:

-> ALTER TABLE <> DROP COLUMN <>;
-- Deletar coluna da tabela


São comandos básicos, mas podem ser bastante útil de acordo com necessidade de cada um...


Abrsss...

Submeter um concurrent no Oracle EBS de dentro de um código PL/SQL com data de execução dinâmica (FND_REQUEST.SUBMIT_REQUEST)

E ai pessoal!!!! Blz???

Hoje vou mostrar uma solução simples para um problema que tive, talvez alguém não conheça essa função e suas opções...

A situação é seguinte, precisamos executar um concurrent todo último dia do mês e não pode ser sábado ou domingo.

Na minha primeira visão da solução, imaginei o próprio schedule do concurrent, colocando na opção "Em dias específicos", porém, lá só tem a opção de ultimo dia, ele não vai se importar se o dia é sábado ou domingo...

Minha idéia é submeter o concurrent de dentro do meu PL/SQL, pega o último dia do mês seria simples, verificar se é sábado ou domingo também é simples, só não sabia se conseguiria colocar uma data para iniciar a execução do concurrent usando o FND_REQUEST.SUBMIT_REQUEST.

Pra quem não conhece o FND_REQUEST.SUBMIT_REQUEST, ela é um API da Oracle que irá submeter o concurrent do seu PL/SQL... guarda esse nome, que com certeza irá usar algum dia.

Depois de uma pesquisada... descobri um parâmetro do FND_REQUEST.SUBMIT_REQUEST que se coloca a data de execução, é somente preencher o parâmetro START_TIME.

Sempre que utilizava o FND_REQUEST.SUBMIT_REQUEST colocava somente os parâmetros obrigatórios e argumentos, não conhecia o START_TIME.

Assim, a solução ficou simples, montei o meu código da seguinte maneira, peguei o ultimo dia do mês com a query abaixo e verifiquei se é sábado ou domingo:

SELECT DECODE( TO_CHAR(LAST_DAY(ADD_MONTHS(SYSDATE,1)),'D')
, '1', TO_CHAR(LAST_DAY(ADD_MONTHS(SYSDATE,1))-2,'DD-MON-RRRR ')
, '7', TO_CHAR(LAST_DAY(ADD_MONTHS(SYSDATE,1))-1,'DD-MON-RRRR ')
, TO_CHAR(LAST_DAY(ADD_MONTHS(SYSDATE,1)),'DD-MON-RRRR ')
) '14:00:00'
INTO v_date_submit
FROM dual;

Com o resultado executei a FND_REQUEST.SUBMIT_REQUEST passando a data que select acima retornou no parâmetro START_TIME.

v_request_id := fnd_request.submit_request( application => 'XXFND' -- Aplicação do concurrent
, program => 'XXCONCURRENT' -- Nome do concurrent
, description => 'Meu Concurrent' -- Descrição do concurrent
, start_time => v_date_submit -- Data de Execução do concurrent
, argument1 => 'S' -- Parâmetro do concurrent
, argument2 => '1060' -- Parâmetro do concurrent
);

Ai é só sair para o abraço!!!!!!

Um exemplo de como o programa ira funcionar: Hoje é dia 30/04/2009, o usuário submete o concurrent. O programa vai fazer todo o processo, buscar o ultima dia do mês seguinte 29/05/2009 e submeter o concurrent para rodar nesta data. Quando chegar no dia 29/05/2009 ele vai fazer processo, buscar o ultima dia do mês seguinte 30/06/2009 e submter o concurrent para rodar nesta data... e assim vai longe... até alguém cancelar o concurrent schedulado.

Espero que a dica acima ajude algum profissional necessitado... heheheheeeeeeeeee



Absss