[PostgreSQL] Truncate Table and Reset Sequence

If we need that after TRUNCATE table, also reset the SEQUENCE then we can do this step :

1. Set the minimum value of the sequence

alter sequence mytable_id_seq minvalue 0 start with 1;

2. Now either reset it:

SELECT setval('mytable_id_seq', 0)

OR we can reset it while truncating:

truncate mytable restart identity;

[Oracle EBS] GL Journals Stuck With Funds Status In Process

Our finance team has an issue with their journals. The GL Journal Batch is stuck with Funds Reservation “In Process”. This journal cannot be posted or edited.

 

CAUSE

The issue usually has been caused by getting a connection/network error or PC hanging while in the process of reserving Funds for a GL Journal Entry.

SOLUTION

A datafix has been required to fix these issues. The datafix essentially clears out gl_bc_packets & gl_bc_packet_arrival_order of any fund reservation entries for the batch & sets the je batch back to an an unreserved status.  Then the user should take another shot at reserving the journal.

To fix the problem Journal Entries follow these steps.

1.  Get the JE_BATCH_ID using the batch NAME from GL_JE_BATCHES.

         SELECT JE_BATCH_ID
         FROM GL_JE_BATCHES
         WHERE NAME = '000-30062018-4251.02 02-JUL-2018 11:16:31'

2.  Delete all of the records out of GL_BC_PACKETS
         
         select * from gl_bc_packets where je_batch_id='3219763'
        
         DELETE GL_BC_PACKETS WHERE JE_BATCH_ID = '3219763'
        

3.  Change the BUDGETARY_CONTROL_STATUS = R in the GL_JE_BATCHES table @
for the specific JE_BATCH_ID.
        
         select * from GL_JE_BATCHES WHERE JE_BATCH_ID = '3219763' --status asli U
        
         UPDATE GL_JE_BATCHES
         SET BUDGETARY_CONTROL_STATUS = 'R' WHERE JE_BATCH_ID ='3219763'

Reference : 

- Oraclefedapps

Manajemen Risiko Keamanan Data

Akses jaringan internet di lingkungan kerja, serta kebebasan dalam menggunakan perangkat seperti MP3, USB, flashdisk, CD dan lainnya di kantor menjadikan kejadian pencurian data rentan terjadi. Oleh karena itu, perusahaan perlu mengambil sejumlah langkah untuk mengamankan data di lingkungan kerja.

Data merupakan sesuatu yang sangat vital bagi bisnis. Jika data sensitif sampai jatuh ke tangan yang salah dan kemudian disalahgunakan, dampaknya bisa sangat buruk, seperti pelanggan atau nasabah diambil alih, rahasia perusahaan diketahui, sehingga dapat mempengaruhi daya saing bisnis dalam industri.

Berikut ini adalah tahap-tahap yang dapat Anda lakukan dalam mengelola risiko keamanan data di lingkungan kerja.

1. Pengukuran Risiko
Pertama, lakukan risk assessment, yakni pengukuran risiko. Lakukan analisa mengenai risiko-risiko data apa saja yang mungkin dicuri, peran karyawan mana saja yang terekspos terhadap risiko, juga analisa bagaimana kebijakan teknologi di lingkungan kerja.

Pada umumnya, data-data yang rentan untuk dicuri antara lain adalah:
- Informasi rahasia
- Rahasia dagang
- Informasi hubungan dengan pelanggan, supplier, dan partner bisnis lainnya
- Informasi hubungan dengan prospek pelanggan
- Informasi mengenai tenaga kerja, dan skill-nya

2. Analisa dan Langkah Mengelola Risiko
Selanjutnya, analisa karyawan mana saja yang berpotensi untuk menghadirkan risiko tersebut. Biasanya adalah karyawan yang bisa langsung mengakses data dan informasi tersebut di atas, yang pada umumnya tidak tersedia secara bebas di perusahaan. Untuk mencegah risiko yang datangnya dari karyawan, maka dalam klausul kontrak dapat dimasukkan mengenai batasan-batasan bagi karyawan dalam mengakses dan memperlakukan data dan informasi tersebut.

Misalnya, karyawan tidak diperkenankan untuk membawa data dan informasi keluar dari kantor, kemudian seluruh hasil pekerjaan yang dilakukan oleh karyawan adalah milik kantor dan tidak boleh dibawa ketika karyawan sudah tidak bekerja disana lagi, tidak boleh dibagi dengan orang lain, dan sebagainya. Anda juga harus membuat konsekuensi yang jelas mengenai pelanggaran peraturan ini.

Lalu bagaimana dengan kebijakan mengenai penggunaan hardware dan software yang selama ini dikeluarkan oleh kantor? Apakah kontrolnya sudah efektif? Hardware dan software merupakan perangkat yang menyimpan data-data Anda, sehingga perlu diterapkan kebijakan dan kontrol yang ketat. Berikut ini adalah langkah-langkah yang dapat Anda ambil dalam mengelola risiko keamanan data.

Selalu gunakan password untuk mengakses database, dokumen dan file yang mengandung data dan informasi yang sensitif. Ini perlu untuk membatasi supaya hanya orang-orang tertentu saja yang dapat mengakses data dan informasi tersebut.

Amankan jaringan Anda dengan firewall dan antivirus, untuk mencegah pihak luar atau hacker menyusup ke dalam jaringan kantor Anda; mengirimkan trojan, virus atau spyware; dan mencuri data dan informasi yang sensitif.

Terapkan kebijakan penggunaan hardware yang ketat, seperti melarang perangkat eksternal seperti flash disk, MP3 player, hard disk external, CD, dan sejenisnya yang dapat digunakan untuk menyimpan data. Jangan ada CD/DVD writer, kecuali beberapa PC yang digunakan khusus untuk itu dan dikelola administrator. .

Anda juga dapat mengurangi risiko dalam menyimpan data sensitif dengan cara membuang data-data yang sudah tidak digunakan lagi. Namun Anda harus menyortir dengan ketat, jangan sampai data yang masih diperlukan oleh divisi lain terbuang. Sesuaikan juga dengan regulasi, yang mungkin mensyaratkan Anda untuk menyimpan data-data tertentu.

Kadang, perusahaan juga punya partner outsourcing yang menyimpan data-data, termasuk data sensitif. Jika demikian, maka tugas perusahaan harus menjamin bahwa partner outsourcing dapat menjaga data-data tersebut dengan serius. Mereka juga harus memahami konsekuensi jika data tersebut bocor ke tempat lain.

Data sensitif biasanya dijaga oleh karyawan-karyawan tertentu saja yang berkepentingan. Karena data itu begitu penting, oleh karena itu Anda harus memberikan reward yang pantas juga bagi karyawan tersebut, supaya memastikan bahwa karyawan tersebut menjaga datanya dengan baik. Jika tidak demikian, maka karyawan tersebut bisa saja lengah atau malah tergoda untuk menjual data ke pihak lain.

Terakhir, masalah mengamankan data ini, karena sifatnya strategis, maka harus dibangun awareness kepada seluruh karyawan di organisasi. Perusahaan harus menekankan pentingnya menjaga data sesuai dengan kebijakan dan prosedur yang sudah berlaku, serta konsekuensinya jika terjadi pelanggaran.

[Oracle EBS] Fixed Asset Error APP-OFA-48392 in Asset Workbench

We have some issue when attempting to add a new asset in Assets Workbench, the following error occurs.

ERROR
-----------------------
APP-OFA-48392 Assets Transaction upgrade is either running or incomplete for one or more reporting currencies associated with primary depreciation book.  You must first complete the upgrade before entering transactions in this book

ROOT CAUSE :

There were already assets in the FA Book when the MRC created.

SOLUTION :

[Linux] Upgrade PHP 5 to PHP 7 using Yum on Oracle RHEL 6.3 Santiago

My Apache Web Server was running PHP version 5.3. But my developer need to use PHP 7.0, because they running on Laravel Framework 5.5. So I decided to upgrade PHP 5.3 to PHP 7.0. Although this is a development web server, I don’t want to disturb the existing setup and also, I don’t want to have multiple versions on PHP installed. So it should be a pure upgrade of PHP.

My environment is :

[root@devapp etc]# cat /etc/redhat-release

Red Hat Enterprise Linux Server release 6.3 (Santiago)

Here's what I've done to upgrade PHP.
1. Configure REMI Repository

# wget https://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
# rpm -Uvh epel-release-6-8.noarch.rpm

# wget http://rpms.famillecollet.com/enterprise/remi-release-6.rpm
# rpm -Uvh remi-release-6.rpm

2. Activate REMI Repository

# yum repolist

# yum-config-manager --enable remi-php70

3. Upgrade PHP 5.3 to PHP 7.0

# yum --showduplicates list php
# yum update php

4. Verify the PHP version

# php -v

5. Restart Web Server

# service httpd restart

[Linux] Install php-mbstring On ORHEL 6.3

I am running Oracle Red Hat Enterprise Linux Server release 6.3 (Santiago) with PHP Version 5.3.3 and Apache/2.2.15 (Oracle) installed.

Problem :
Recently, I have a new apps and got some errors:

Fatal error: Call to undefined function mb_detect_encoding()

Cause:

This error occurs because the new application requires mbstring extension.

Solution:
So here is the solution.
1. Check phpinfo();
It seem that extension does not appear in phpinfo.

2. Check Extension
[root@intranet newapps]# rpm -qa | grep php-mbstring
[root@intranet newapps]# rpm -qa | grep php
php-pear-1.9.4-4.el6.noarch
php-ldap-5.3.3-3.el6_2.8.x86_64
php-common-5.3.3-3.el6_2.8.x86_64
php-xml-5.3.3-3.el6_2.8.x86_64
php-cli-5.3.3-3.el6_2.8.x86_64
php-gd-5.3.3-3.el6_2.8.x86_64
php-pdo-5.3.3-3.el6_2.8.x86_64
php-devel-5.3.3-3.el6_2.8.x86_64
php-5.3.3-3.el6_2.8.x86_64

mbstring extension is not currently installed

3. Search On Yum
[root@intranet newapps]# yum search php-mbstring
Loaded plugins: refresh-packagekit, security
==================================== N/S Matched: php-mbstring ====================================
php-mbstring.x86_64 : A module for PHP applications which need multi-byte string handling

4. Install mbstring extension
[root@intranet newapps]# yum install php-mbstring

5. Restart apache
[root@intranet newapps]# service httpd restart

6. Check phpinfo();
mbstring already installed and appear in phpinfo();
We can edit the mbstring value in /etc/php.ini

7. Check the new apps

[Oracle EBS] ORA-01591 In-Doubt Transactions

Problem :
ORA-01591: lock held by in-doubt distributed transaction.
Saat sedang melakukan query ke database oracle untuk mengambil data tertentu dengan filter/kondisi where, tau2 terjadi error. Padahal itu adalah query dengan kondisi where biasa dan tidak terlalu rumit. Saat dicoba query tanpa kondisi where, tidak terjadi error. Errornya adalah :
ORA-01591: lock held by in-doubt distributed transaction 9.4.660456
Menurut oracle, penjelasan mengenai ORA-01591, adalah sebagai berikut:

ORA-01591 lock held by in-doubt distributed transaction string
Cause: An attempt was made to access resource that is locked by a dead two-phase commit transaction that is in prepared state.
Action: The database administrator should query the PENDING_TRANS$ and related tables, and attempt to repair network connection(s) to coordinator and commit point. If timely repair is not possible, the database administrator should contact the database administrator at the commit point if known or the end user for correct outcome, or use heuristic default if given to issue a heuristic COMMIT or ABORT command to finalize the local portion of the distributed transaction.

Cause :
Kondisi error tersebut disebut dengan In-Doubt Transactions.  Error terjadi saat kita mempunyai 2 buah proses transaction yang bersamaan dan saling menunggu untuk melakukan commit atau rollback sedangkan transaction yang ditunggu sudah crash/dead sehingga kondisi commit tidak pernah terjadi sehingga terjadilah kondisi lock. Hal itu terjadi karena :
– Mesin server yang menjalankan Oracle Database crash
– Koneksi Jaringan yang terputus saat terjadi proses transaction
– Kesalahan Aplikasi.
Penjelasan lebih lengkap bisa dilihat di Oracle® Database Administrator’s Guide

Solution :
1. Masuk ke sqlplus atau toad atau tools lainnya, connect sebagai sysdba.

2. Jalankan querty untuk melakukan pengecekan transaction id
SQL> select local_tran_id from dba_2pc_pending;
LOCAL_TRAN_ID
———————
1.9.4.660456

3. Lakukan rollback.
SQL> ROLLBACK FORCE '9.4.660456';
Rollback complete.
SQL> EXECUTE dbms_transaction.purge_lost_db_entry('9.4.660456');
PL/SQL procedure successfully completed.
SQL> commit;
Commit complete.

4. Cek lagi
SQL> select local_tran_id from dba_2pc_pending;
no rows selected

Oke done. Problem solved.