LANGKAH 1: TENTUKAN APAKAH LAPORAN KEUANGAN MENGGUNAKAN TABEL AA:

Sebelum menutup GL atau melakukan langkah-langkah apa pun dalam artikel ini, jalankan laporan keuangan yang biasanya Anda jalankan untuk menyeimbangkan Saldo Percobaan GL. Berdasarkan yang Anda temukan, ikuti metode yang sesuai:

-METHOD 1 - JIKA BENAR: Jika laporan Keuangan sudah benar dan sesuai dengan GL, Anda dapat melanjutkan dengan langkah 2-8 di artikel ini, yang masih harus diselesaikan agar tidak terjadi kesalahan AA selama proses penutupan akhir tahun GL.

Catatan: Jika menggunakan sistem pelaporan yang hanya membaca secara langsung dari tabel GL (seperti penyedia Warisan dalam Management Reporter saat membaca dari perusahaan GL atau alat pelaporan lainnya)] untuk Laporan Keuangan, Anda dapat melanjutkan ke Langkah 2 karena data AA tidak memengaruhi pelaporan keuangan.


-METHOD 2 - JIKA TIDAK BENAR:Namun, jika laporan keuangan Anda tidak benar, kemungkinan besar karena tabel AA yang sedang digunakan dan data AA tidak cocok dengan data GL. Untuk memverifikasi data AA, anda harus terlebih dahulu menjalankan skrip SQL yang disediakan di KB 2910626 selain langkah-langkah selanjutnya dalam artikel ini.  

Catatan: Data Management Reporter membaca dari tabel AA (dan GL), atau penyedia Warisan yang digunakan dengan Management Reporter dapat dibaca dari perusahaan AA.

Langkah-langkah untuk Metode 2:

a.) Pertama, jalankan semua skrip di KB 2910626 untuk memverifikasi data AA dengan data GL.   

Laporan Keuangan dari Manajemen Pelaporan tidak cocok dengan Laporan Saldo Percobaan Ledger Umum di Microsoft Dynamics GP
http://support.microsoft.com/help/2910626

b.) Setelah menyelesaikan langkah-langkah dalam KB 2910626, kembali ke KB ini dan lanjutkan dengan langkah-langkah yang tercantum di bawah ini. (Perhatikan bahwa langkah 2 dan langkah 4 juga ada di KB 2910626, tetapi kami menyarankan untuk memeriksa kembali hal ini, karena mereka tidak boleh mengembalikan hasil apa pun jika Anda sudah memperbaiki data ini.)

 

LANGKAH 2: MEMVERIFIKASI DATA AA UNTUK TAHUN YANG TUMPANG TINDIH

Jalankan skrip ini untuk memastikan Anda tidak mempunyai tahun yang tumpang tindih di tabel AAG30000 Buka dengan tabel riwayat AAG40000. Setiap tahun berbeda seharusnya hanya ada dalam satu tabel atau yang lainnya, tetapi tidak keduanya.

select distinct(YEAR1) from AAG30000

select distinct(YEAR1) from AAG40000

-Jika Anda menemukan tahun yang tumpang tindih di kedua tabel, maka sebaiknya Anda membuka insiden dukungan untuk bantuan. Kasus dukungan dapat dikenakan biaya karena masalah ini biasanya disebabkan oleh pengi impor. Perlu diingat bahwa jika perbaikan data diperlukan, hal ini mungkin perlu dirujuk, yang merupakan pengeluaran yang dapat ditagihkan untuk Anda.
 

LANGKAH 3: VERIFIKASI TAHUN DI ANTARA TABEL YANG TERBUKA/RIWAYAT YANG COCOK DENGAN AA/GL:

Berikutnya, pastikan tahun dalam tabel AA berada pada tahun yang terbuka atau tertutup yang sama dengan tabel GL. Tabel AAG30000 dan GL20000 yang terbuka harus memiliki tahun yang sama. Tabel riwayat AAG40000 dan GL30000 harus berisi tahun-tahun tertutup yang sama.

select distinct(YEAR1) from AAG30000

select distinct(OPENYEAR) from GL20000

select distinct(YEAR1)from AAG40000 order by YEAR1

select distinct(HSTYEAR) from GL30000 order by HSTYEAR

-Jika Anda menemukan tahun dalam tabel yang terbuka AAG30000 SEBELUM tahun Anda menutup, Anda juga harus melakukan LANGKAH-LANGKAH UNTUK MEMINDAHKAN DATA KE RIWAYAT di bawah ini serta untuk memindahkan data tahun historis ke riwayat. Tabel AAG30000 seharusnya hanya memiliki data untuk tahun yang saat ini terbuka dalam GL. Jika mencoba menutup tahun dalam GL, Anda akan melihat pesan ini:  

Gunakan skrip di atas untuk menentukan apakah Anda perlu menjalankan LANGKAH-LANGKAH UNTUK MEMINDAHKAN DATA KE RIWAYAT, agar pesan di atas tidak terjadi selama proses penutupan akhir tahun GL.


LANGKAH-LANGKAH UNTUK MEMINDAHKAN DATA KE RIWAYAT:
Pada kali pertama menutup GL pada versi yang lebih tinggi dari GP 10.0 SP2 atau yang lebih tinggi (dengan AA yang diaktifkan), Anda akan diminta untuk memindahkan data AA ke riwayat sebelum sistem memungkinkan Anda untuk menutup tahun GL. Sistem akan memverifikasi bahwa data AA berada dalam seri terbuka/riwayat tabel AA yang terkait, karena data GL terletak dalam tabel terbuka/riwayat pada GL. Jika bukan itu kasusnya, Anda akan menerima pesan untuk menjalankan Utilitas Pemindahan ke Riwayat untuk AA sebelum dapat melanjutkan dengan penutupan Akhir Tahun GL.  ( Rutinitas ini seharusnya hanya perlu dijalankan SEKALI setelah Anda memutakhirkanGP 10.0, lalu Anda tidak harus menjalankannya lagi.  Tujuannya hanya satu kali. Utilitas ini tidak akan memperbaiki tahun duplikat di antara tabel AA atau data rusak di lain waktu.)

Ingat, jika belum menutup tahun GL (dengan AA diaktifkan) setelah menginstal paket layanan setelah SP2 untuk versi 10.0, atau memutakhirkan ke GP 2010, Anda mungkin menerima pesan yang mengatakan " Anda harus mengonsolidasi transaksi dan detail transfer ke utilitas riwayat untuk menutuptahun". Kode ditambahkan untuk proses penutupan yang akan membandingkan tahun dalam tabel terbuka AA dengan tahun-tahun historis dalam Penyetelan Periode Fiskal Perusahaan. Jika ada data AA dalam seri tabel AAG3000X untuk tahun historis, Anda akan menerima kesalahan. Ikuti langkah-langkah ini untuk mengonsolidasi tahun tersebut:

1.) Pada menu Microsoft Dynamics GP, arahkan ke Alat,arahkan ke Utilitas,arahkan ke Keuangan,arahkan ke Akuntansi Analitik,lalu klik Pindahkan Data ke Riwayat.

2.) Tahun paling lama akan menjadi default karena sistem ditemukan dalam tabel AAG3000x yang terbuka. Anda hanya dapat berpindah satu tahun pada satu waktu.

3.) Pilih opsi yang sesuai: Transfer detail transaksi ke riwayat – Opsi ini akan memindahkan data detail AA dari tabel terbuka ke riwayat dan tidak

ada entri BBF yang akan dibuat. Anda harus memastikan tidak ada entri BBF dalam tabel AA jika tidak, Anda tidak akan dapat memilih opsi ini. Opsi ini hanya memindahkan data dari tabel AAG30000 ke tabel AAG40000.

Mengonsolidasitransaksi dan detail transfer ke histor y – Opsi ini akan memindahkan catatan detail AA dari yang terbuka ke tabel riwayat dan membuat entri BBF. Namun, Anda harus memiliki opsi yang disebutkan sebelumnya agar entri BBF dapat dibuat. Opsi ini akan mengonsolidasi saldo semua kode dimensi transaksi pada tahun tertutup (yang ditandai untuk dikonsolidasi) dan mentransfer informasi AA ke tabel riwayat.

Catatan Saldo konsolidasi akan diteruskan ke tahun baru. Entri BBF dibuat dari tahun-tahun ditutup.

Laporan pratinjau transfer cetak saja – Ini akan memungkinkan Anda untuk melihat transaksi yang akan dipindahkan tanpa benar-benar memindahkan data. Laporan pratinjau menampilkan konsolidasi yang akan dibuat.

Catatan Opsi ini tidak mengubah data.

4.) Klik OK.

5.) Ulangi proses ini untuk setiap 'riwayat' tahun. (Ketika tahun berada dalam tabel terbuka AAG30000, tetapi berada dalam tabel riwayat GL30000. Catatan AA yang terbuka dengan tahun lalu harus dipindahkan ke tabel riwayat AA agar sesuai dengan catatan terkait dalam tabel riwayat GL.)

Catatan: Jika menjalankan kembali skrip tahun yang berbeda di 'LANGKAH 3' di atas lagi, Anda akan mendapatkan tahun yang berbeda untuk dicocokkan antara tabel AA dan GL yang terbuka, serta riwayat tabel AA dan GL.

 

LANGKAH 4: PERIKSA TABEL AA UNTUK ID HEADER YANG TUMPANG TINDIH

Jalankan skrip ini terhadap database perusahaan lihat apakah ID header yang sama juga ada di antara tabel:

select * from AAG30000 where aaGLHdrId in (select aagLHDrId from AAG40000)

- Jika Anda menemukan ID header duplikat dari kedua tabel, maka sebaiknya Anda membuka insiden dukungan untuk mendapatkan bantuan. Kasus dukungan dapat dikenakan biaya. Perlu diingat bahwa jika perbaikan data diperlukan, hal ini mungkin perlu dirujuk, yang merupakan pengeluaran yang dapat ditagihkan untuk Anda.

Ini akan terjadi jika Anda memulihkan database Dynamics yang lebih lama di atas database Dynamics saat ini, sehingga angka tersedia berikutnya yang disimpan di tabel AAG00102 dalam database Dynamics diatur kembali. GP terus meningkat dari nilai-nilai ini, meskipun mungkin sudah digunakan dan akan menghasilkan nilai aaGLHdrID yang sama untuk nilai YEAR1 yang berbeda.
 

LANGKAH 5: MEMPERBARUI NILAI AACOPYSTATUS

Berikutnya periksa nilai aacopystatus yang tidak benar dalam tabel AAG40001. Jalankan skrip ini:

select count(*) from AAG40001 where aaCopyStatus<>8 

Jika skrip di atas mengembalikan hasil, Anda mungkin ingin memperbarui aaCopyStatus menjadi '8' sebelum menjalankan GL Year Close: (Nilai '8' adalah nilai yang akan diterima oleh proses penutupan akhir tahun.)

update AAG40001 set aaCopyStatus=8

LANGKAH 6: TINJAU PENYIAPAN DIMENSI YANG AKAN DISERTAKAN PADA AKHIR TAHUN

Gunakan dua langkah di bawah ini untuk mengaktifkan opsi Perusahaan guna menyertakan dimensi AA pada akhir tahun, lalu untuk menandai dimensi individual yang ingin disertakan dalam akhir tahun. Hal ini akan menghasilkan entri dalam tabel AAG30003 dengan aaGLHdrID yang sama dengan entri BBF dalam tabel AAG30000/AAG30001/AAG30002. Ini adalah proses dua langkah sebagai berikut:

Jika belum menutup Ledger Umum, ikuti langkah-langkah berikut untuk memastikan dimensi ditandai dengan benar agar disertakan dalam proses penutupan:

1. Tandai opsi penyiapan untuk menyertakan Akuntansi Analitik pada akhir tahun sebagai berikut:

   1. Pada menu Microsoft Dynamics GP, arahkan ke Alat,arahkan ke Penyiapan,arahkan ke Perusahaan,arahkan ke Analytical Accounting,lalu klik Opsi.

   2. Klik untuk memilih kotak centang Sertakan di Penutupan Akhir Tahun, lalu klik OK.
      
      
      Catatan Opsi ini hanya untuk mengaktifkan fungsionalitas untuk membuat entri Balance Brought Forward pada dimensi. Data Akuntansi Analitik tetap akan berpindah ke tabel seri AAG40000 ketika General Ledger ditutup terlepas dari apakah opsi ini ditandai.

2. Secara individual tandai dimensi yang akan disertakan pada akhir tahun sebagai berikut:

   1. Pada menu Kartu, arahkan ke Keuangan,arahkan ke Analytical Accounting,lalu klik Dimensi Transaksi.

   2. Dalam daftar Dimensi Trx, klik dimensi yang ingin Anda sertakan dalam proses penutupan akhir tahun.

   3. Di area Penutupan Akhir Tahun, klik untuk memilih kotak centang Konsolidasikan Saldo selama Akhir Tahun lalu klik Simpan.

   4. Ulangi langkah b dan c untuk setiap dimensi yang ingin disertakan dalam proses penutupan akhir tahun.

Catatan: Jika Anda menggunakan MR, dan kotak centang di atas tidak ditandai, jumlah saldo awal mungkin akan terlewatkan jika data dimensi AA BBF tidak dibuat selama akhir tahun dan Anda melaporkan data AA. 



LANGKAH 7 - VERIFIKASI MASTER AKUN AA

Selalu bagus untuk memverifikasi bahwa tabel Master Akun AA (AAG00200) cocok dengan tabel Master Akun GL (GL00100) sebelum memproses akhir tahun. Jika akun hilang, hal itu akan menyebabkan entri BBF di AA menjadi tidak benar. Jalankan skrip di bawah ini terhadap database perusahaan untuk memverifikasi bahwa Tabel Master Akun GL, Master Indeks Akun GL, dan Master Akun AA semuanya memiliki jumlah rekaman yang sama:

select count(*) from GL00100

select count(*) from GL00105

select count(*) from AAG00200

• Jika tabel Master Akun AA memiliki rekaman LEBIH SEDIKIT dari tabel GL00100, gunakan skrip di bawah ini untuk menyisipkan akun GL yang hilang:

insert into aag00200 
ACTINDX, aaAcctClassID,aaChangeDate,aaChangeTime)
select ACTINDX, 0, convert(char(10),getdate(),111), convert(char(12),getdate(),114)
from GL00100 where ACTINDX not in (select ACTINDX from aag00200)

• Jika tabel Master Akun AA memiliki rekaman LEBIH BANYAK dari tabel GL00100, gunakan skrip di bawah ini untuk menghapus data tambahan:

Delete AAG00200 where ACTINDX not in (Select ACTINDX from GL00100)

• Jika tabel GL00105 tidak cocok, lihat

KB 855963 langkah tentang Cara membuat ulang tabel Indeks Master Akun (GL00105). 





LANGKAH 8 - PERIKSA ENTRI GL/AA (GP2015/GP2016 SAJA)

Terjadi masalah dengan entri Gl Reversing yang memposting ke tahun sebelumnya dalam setiap versi, seperti yang ditunjukkan di bawah ini.  Jalankan skrip di bawah ini terhadap database perusahaan.  Tinjau hasil apa pun seperti yang telah diketahui untuk setiap versi.  Jika ada bantuan yang diperlukan, silakan buka kasus dukungan dan referensikan masalah kualitas. 

Jalankan skrip ini untuk meninjau semua entri Pembalikan yang diposting ke tahun historis. 

--------------------------------

Select distinct(a.JRNENTRY) from GL20000 a bergabung dengan GL30000 b
on a.JRNENTRY = b.JRNENTRY
di mana a.DOCDOC = 'GJ'
dan a.TRXSORCE seperti 'GLREV%'
dan b.TRXSORCE seperti 'GLTHS%'

----------------------------------

Tinjau hasilnya seperti yang diuraikan di bawah ini untuk versi yang Anda gunakan:

Microsoft Dynamics GP 2016 (Masalah kualitas #91834)

 Bandingkan rekaman antara tabel GL dan tabel AA untuk setiap JE# yang dikembalikan di atas, karena hasil dapat berbeda tergantung pada apakah akun P&L digunakan, dan apakah digunakan pada tingkat transaksi atau tingkat kumpulan yang diposting.  Pembaruan manual yang diperlukan mungkin: 

• Perbarui SEQNUMBR dalam tabel GL20000 untuk entri 'GLREV' agar sesuai dengan SEQNUMBR dalam tabel AAG30001. (Jika menggunakan MR, perlu menggunakan SEQNUMBR dari tabel AA agar MR dapat membacanya.)

• Perbarui ACTINDX dalam tabel AAG30001 untuk entri "GLREV' agar sesuai dengan ACTINDX dalam tabel GL20000. (Tabel AA memiliki indeks akun Retained Earnings (AA tidak benar memiliki indeks akun Pendapatan yang Dipertahankan di entri pembalikan.)

• Memverifikasi jumlah rekaman di AAG30002 sama dengan jumlah rekaman di AAG30001 untuk catatan aaGLHdrID untuk JE.

Buka masalah kasus dukungan dan kualitas referensi #91834 jika bantuan diperlukan. 

PEMBARUAN: Masalah ini telah diperbaiki dalam Perbaikan Cepat Januari untuk GP 2016 (16.00.0675) dan GP 2018 (18.00.0438). 

Microsoft Dynamics GP 2015 (Masalah kualitas #88914)

Tinjau tabel AA untuk setiap JE# yang dikembalikan di atas .  Pembaruan manual yang diperlukan mungkin:

• Memverifikasi jumlah rekaman di AAG30002 sama dengan jumlah rekaman di AAG30001 untuk catatan aaGLHdrID untuk JE.

• Tinjau tabel AAG30000 dan AAG40000 untuk setiap JE# yang dikembalikan.  Cari catatan untuk entri 'GLREV' yang berada di tabel seri AAG30000. Catatan AA untuk entri 'GLREV' harus berada dalam tabel AAG30000 hanya karena entri pembalikan berada di tahun baru, dan tidak boleh berada dalam tabel seri AAG40000.  Rekaman duplikat ini akan menyebabkan laporan MR menjadi overstated jika melaporkan AA.

Buka masalah kasus dukungan dan kualitas referensi #88914 jika bantuan diperlukan. 

PEMBARUAN: Masalah ini telah diperbaiki dalam GP 2016 RTM.   

LANGKAH 9 - MASALAH AA BBF YANG TIDAK BENAR (****Masalah yang diketahui untuk GP 2016 saja***)

**CATATAN PENTING UNTUK PENGGUNA DYNAMICS GP 2016***

**Anda harus berada di kamus GP 16.00.0675 atau lebih tinggi, (atau kamus AA 16.00.0645 atau yang lebih tinggi) sebelum Anda menutup Dynamics GP 2016 agar saldo awal yang benar kembali**

Terdapat masalah kualitas yang diketahui #91502 ketika menutup tahun GL dengan AA.  Jika memiliki akun GL dengan saldo $0 dan meluncurkan kode AA, kode AA BBF tidak akan benar.  Ini bukan masalah di GP 2015 atau GP 2013.  

Perbaikan telah disertakan untuk masalah ini dalam pembaruan patch desember (KB 4056559) untuk Microsoft Dynamics GP 2016.  Meskipun rilis Desember 2017 disebut sebagai Pembaruan Akhir Tahun Penggajian Kanada2017,data tersebut harus diinstal oleh semua pelanggan A.S. yang memerlukan perbaikan BBF AA yang disertakan.  Anda sangat disarankan untuk menginstal pembaruan patch Desember ini sebelum menutup GL jika menggunakan AA dan memiliki akun GL dengan saldo nol, untuk semua penginstalan (A.S., Kanada, dll) yang menggunakan AA. 

Perhatikan bahwa versi Dynamics GP 16.00.0641 tidak berubah antara Pembaruan Year-End As 2017 (rilis November/KB 4046341) dan Pembaruan Year-End Gaji Kanada 2017 (Rilis Desember/KB 4056559). Namun kamus AA akan diperbarui dari 16.00.0552 ke 16.00.0645. (Periksa kotak Centang | Tentang | Microsoft Dynamics GP Tambahan | Tentang Analytical Accounting.) Kode AA diperlukan dalam rilis bulan Desember untuk mengatasi masalah AA/BBF ini. 

LANGKAH 10 - JALANKAN UJI TUTUP

Selalu buat cadangan saat ini sebelum memulai proses penutupan akhir tahun GL. Sebaiknya uji coba untuk menjalankan penutupan akhir tahun GL di perusahaan uji terlebih dahulu guna memastikan Anda tidak mendapatkan kesalahan apa pun. Proses penutupan akhir tahun GL adalah hal yang sebenarnya membuat keseimbangan yang membawa entri jurnal maju (BBF), dan memindahkan catatan untuk tahun yang akan Anda tutup di tabel General Ledger dan Analytical Accounting. Entri BBF dibuat dalam tabel GL dan AA. Lihat proses yang diuraikan dalam KB 888003 untuk prosedur penutupan akhir tahun untuk Ledger Umum.

Untuk informasi selengkapnya, klik nomor artikel berikut ini untuk melihat artikel di Basis Pengetahuan Microsoft:

888003 Year-End penutup untuk Ledger Umum di Microsoft Dynamics GP

-----------------------------------------------------------------------------------------------
CATATAN: Akhir tahun ditutup dengan AA pada SQL 2019 gagal
Jika menggunakan GP 18.2 dengan SQL 2019 dan AA yang dimuat, penutupan akhir tahun GL akan gagal dengan pesan di bawah ini: (Versi SQL sebelumnya berfungsi dengan baik.  Hanya gagal pada SQL 2019.  Masalah ini telah diperbaiki dalam Perbaikan cepat bulan Februari 2020. Lihat BLOG AA YE untuk detail selengkapnya.)

"Kesalahan internal: Batas layanan ekspresi telah tercapai. Silakan cari ekspresi yang berpotensi kompleks dalam kueri Anda, dan coba sederhanakan ekspresi tersebut."  

------------------------------------------------------------------------------------------------

LANGKAH 11- PERIKSA APAKAH 'AKUN UNIT' DIBERSIHKAN (GP 2013/GP 2015 saja - #86400)

Jika Anda menggunakan Microsoft Dynamics GP 2015 atau Microsoft Dynamics GP 2013 dan menandai kotak centang pada Akun Unit untuk 'HapusSaldo Selama Year-End Tutup ', catatan dalam tabel AAG30002 mungkin masih salah memiliki nilai, dan harus 0,00 agar cocok dengan tabel AAG30001.  (Masalah ini telah diperbaiki di Microsoft Dynamics GP 2016.)

Untuk memastikan bahwa saldo Akun Unit sudah benar dalam tabel AA, jalankan skrip pertama di bawah ini terhadap database perusahaan setelah proses penutupan akhir tahun dijalankan untuk memastikan BBF untuk akun unit diatur ke nol jika ditandai agar dihapus.  Gunakan skrip kedua untuk memperbarui hasil apa pun.

select b.ACTINDX, c.aaGLHdrID, c.aaGLDistID, c.DEBITAMT, c.CRDTAMNT, c.ORDBTAMT, c.ORCRDAMT
from AAG30002 c inner join AAG30001 b
on b.aaGLHdrID = c.aaGLHdrID and
b.aaGLDistID = c.aaGLDistID
inner join GL00100 d on
b.ACTINDX = d.ACTINDX
where d.Clear_Balance = 1 and b.ACCTTYPE = 2 and b.SOURCDOC = 'BBF' 
and (c.DEBITAMT <> 0 or c.CRDTAMNT <> 0 or c.ORDBTAMT <> 0 or c.ORCRDAMT <> 0)

update c set c.DEBITAMT = 0, c.CRDTAMNT = 0, c.ORDBTAMT = 0, c.ORCRDAMT = 0 
from AAG30002 c inner join AAG30001 b
on b.aaGLHdrID = c.aaGLHdrID and
b.aaGLDistID = c.aaGLDistID
inner join GL00100 d on
b.ACTINDX = d.ACTINDX
where d.Clear_Balance = 1 and b.ACCTTYPE = 2 and b.SOURCDOC = 'BBF'
and (c.DEBITAMT <> 0 or c.CRDTAMNT <> 0 or c.ORDBTAMT <> 0 or c.ORCRDAMT <> 0)

LANGKAH 12- VERIFIKASI LAPORAN LEMBAR SALDO

Sebaiknya bandingkan laporan Balance Sheet dalam Management Reporter pada laporan Saldo Percobaan Ledger Umum dari Microsoft Dynamics GP, untuk memverifikasi bahwa saldo akun yang datang ke tahun baru sudah benar. Jika saldo ini tidak cocok, pulihkan ke cadangan Anda dan hubungi Dukungan Microsoft Dynamics GP untuk membuka insiden dukungan untuk bantuan tambahan.

INFORMASI INTERNAL MICROSOFT

Tanggal terakhir diperbarui: 3/12/2021 - cw
Penulis: dspecht; ditulis ulang 2/12/2012 oleh cwaswick, 19/9/2013 - ditambahkan langkah 3 oleh kenhub/cwaswick.
Penulis: lmuelle
Peninjau Teknis: kriszree
Editor: v-andmck