Integrasi Magento kepada SAP: Apa Yang Sebenarnya Rosak

Integrasi Magento kepada SAP jarang rosak pada lapisan sambungan. Ia rosak kerana tiada sesiapa memutuskan, medan demi medan, sistem mana yang memiliki kebenaran, dan apa yang patut berlaku apabila kedua-duanya bercanggah pada pukul tiga pagi ketika sedang promosi.

Memindahkan muatan antara Adobe Commerce dan SAP ialah masalah yang sudah selesai. Yang tidak selesai secara lalai ialah pemilikan, urutan, pengendalian kegagalan, dan penyelarasan. Bridzia telah menghabiskan 14 tahun di atas Adobe Commerce, membina integrasi Magento kepada SAP merentas modul Kewangan, Inventori dan Gudang untuk klien peruncitan, dan senarai pendek kegagalan yang sama muncul dalam hampir setiap projek. Inilah kegagalan tersebut dan cara mereka bentuk untuk menghapuskannya.

Hanyutan stok: kedai dan gudang berhenti bersetuju

Bahagian operasi perasan laman web berkata empat unit ada stok manakala gudang berkata tiada. Dua punca berasingan disalahkan kepada satu pepijat.

Yang pertama, angka stok SAP bukan angka yang boleh dijual. Stok tidak terhad di sesebuah kilang atau lokasi simpanan bukanlah apa yang boleh dijanjikan oleh sebuah kedai dalam talian. Di antara kedua-duanya terletak peruntukan terhadap penghantaran terbuka, stok tersekat dan dalam pemeriksaan kualiti, barangan dalam transit, dan apa jua penimbal keselamatan yang disimpan pasukan rantaian bekalan. Segerakkan kuantiti mentah dan anda sedang menerbitkan satu angka yang memang tidak pernah dimaksudkan untuk dijual.

Yang kedua, kedua-dua sistem menolak pada saat yang berbeza. Adobe Commerce menempah kuantiti apabila pesanan dibuat. SAP lazimnya mengurangkan stok apabila penghantaran diposkan dan pengeluaran barang berlaku, yang mungkin berjam-jam kemudian. Dalam tempoh itu angkanya berbeza secara sah, dan penyegerakan yang naif menulis ganti tempahan yang betul dengan angka gudang yang sudah lapuk.

Reka bentuk untuk mengatasinya dengan mentakrifkan kuantiti boleh dijual sebagai satu formula yang eksplisit, dipersetujui bersama pasukan rantaian bekalan dan dikira di pihak SAP. Kedai dalam talian menerima satu angka dan tidak membuat sebarang pengiraan sendiri. Terbitkan delta yang kerap ditambah satu petikan penuh pada kitaran yang lebih perlahan, capkan setiap mesej dengan cap masa sumber atau nombor jujukan, dan buang mesej yang tiba di luar urutan dan bukan menerapkannya. Kemudian putuskan, sebelum pembinaan, sama ada stok boleh dijual sifar menyekat pembayaran atau mencipta pesanan tertunggak, kerana kedua-duanya aliran pesanan yang berbeza dalam SAP.

Harga: SAP memiliki harga, kedai memiliki promosi

Susunan biasa ialah SAP menjadi sistem rekod bagi harga sementara pemasaran memerlukan harga promosi yang SAP langsung tidak tahu. Itu berkesan sehinggalah kedua-dua sistem menulis ke medan yang sama, dan pada ketika itu harga berkibar antara dua nilai mengikut jadual yang tiada sesiapa dapat jelaskan.

Harga bukan satu nilai. Ia sekurang-kurangnya tiga: harga asas yang SAP miliki, harga promosi yang dilihat pembeli (peraturan katalog Magento, peraturan troli, harga peringkat dan kumpulan pelanggan), dan harga yang benar-benar dicaj bersama pesanan. Asingkan ketiga-tiganya dan konflik itu hilang. SAP menulis hanya ke atribut harga asas. Enjin peraturan Magento mengira segalanya di atasnya dan tidak pernah menulis balik. Pesanan kemudian membawa harga setiap baris dan jumlah seperti yang dicaj, dan SAP menerimanya dan bukan mengira semula daripada rekod syarat. Jika pihak kewangan berkeras mahukan pengesahan semula, persetujui satu toleransi dan satu aliran kerja bagi baris di luarnya, jika tidak setiap pesanan promosi menjadi pengecualian manual.

Bahagian yang tidak menarik dalam hal ini ialah pembundaran. Dua sistem dengan ketepatan perpuluhan, arah pembundaran, dan urutan pengiraan cukai yang berbeza (setiap baris berbanding setiap dokumen) akhirnya akan menghasilkan jumlah yang berbeza satu sen, dan satu sen sudah memadai untuk sesuatu dokumen ditolak dalam modul Kewangan. Tetapkan ketepatan, pembundaran dan asas cukai semasa peringkat seni bina, kemudian uji dengan bakul paling teruk yang boleh anda bina: diskaun troli peratusan yang disebarkan merentas kadar cukai bercampur dengan baris penghantaran berdiskaun di atasnya.

Jurang penyegerakan pesanan: pesanan yang wujud dalam satu sistem sahaja

Satu pesanan dibuat, penghantaran ke SAP gagal. Versi yang jelas itu mudah: ralat yang nyata, satu makluman, satu percubaan semula. Versi yang berbahaya ialah kesamaran. Permintaan itu tamat masa selepas SAP sudah pun mencipta dokumen tersebut, jadi pesanan itu wujud di sana dan kedai dalam talian tidak tahu. Cuba semula secara membuta dan anda kini mempunyai dua pesanan jualan, yang menjadi dua penghantaran dan dua invois, dileraikan dengan tangan oleh pihak kewangan tiga minggu kemudian.

Kebolehulangan bukan pilihan di sini. Hantar satu rujukan luaran yang stabil bersama setiap pesanan, biasanya ID kenaikan Magento, dan biarkan pihak SAP menyemak dokumen sedia ada dengan rujukan itu sebelum mencipta apa-apa. Jika sudah ada, pulangkan nombor dokumennya dan bukan mencipta yang kedua. Percubaan semula kemudian menjadi selamat secara binaan, dan itulah yang membolehkan anda mencuba semula secara agresif.

Sama pentingnya: jangan hantar pesanan itu di dalam permintaan pembayaran. Tulis ia ke satu peti keluar dalam transaksi pangkalan data yang sama yang menyerahkan pesanan itu, dan biarkan seorang pekerja menghantarnya. Proses pembayaran berhenti bergantung pada ketersediaan ERP, dan setiap pesanan memperoleh satu keadaan yang eksplisit: dalam baris gilir, dihantar, diakui dengan nombor dokumen, atau gagal dengan sebab. Jika anda tidak dapat menjawab "pesanan mana yang belum ada dalam SAP" dengan satu pertanyaan, anda tiada model penyegerakan, anda cuma ada harapan.

Percubaan semula yang memburukkan gangguan

Logik cuba semula menyebabkan lebih kurang sebanyak insiden seperti yang dihalangnya. Dua corak menyebabkan kebanyakan kerosakan: gelung cuba semula selang tetap serta-merta, yang menukar gangguan antara muka yang singkat menjadi penafian perkhidmatan yang dilakukan sendiri sebaik baris gilir tersekat, dan cuba semula tanpa had bagi mesej yang tidak akan pernah berjaya, yang meletakkan muatan beracun di kepala baris gilir dan menyekat segala yang di belakangnya.

Kelaskan kegagalan sebaliknya. Masa tamat rangkaian, pertikaian kunci, dan antara muka yang tidak tersedia sementara boleh dicuba semula: gunakan pengunduran eksponen dengan jitter dan had percubaan yang keras. Kegagalan pengesahan seperti rekod induk pelanggan yang hilang, bahan yang tidak sah, atau tempoh pengeposan yang telah ditutup akan gagal dengan cara yang sama selama-lamanya, jadi halakan ia ke baris gilir surat mati yang menyimpan muatan mentah dan teks ralat sebenar, dan maklumkan kepada seseorang. Tambah pemutus litar supaya baris gilir berundur daripada antara muka yang jelas tergendala dan mengalir keluar pada kadar terkawal apabila ia kembali. Kekalkan urutan di mana ia penting, biasanya bagi setiap entiti dan bukan satu jujukan global, supaya satu pembatalan tidak akan sesekali memintas pesanan yang dibatalkannya.

Data induk: rekod yang tidak wujud di sebelah sana

Kebanyakan pesanan yang ditolak ialah masalah data induk yang memakai kostum integrasi. Sebuah produk dicipta dalam Magento tetapi tidak pernah diluaskan dalam SAP bagi organisasi jualan tersebut. Seorang pelanggan tanpa akaun yang sepadan. Ketidakpadanan unit ukuran di mana kedai menjual seunit sedangkan unit jualannya sekotak dua belas. Kaedah penghantaran tanpa pemetaan kepada jenis dokumen.

Putuskan pemilikan bagi setiap objek dan bukan bagi setiap sistem. Dalam praktiknya SAP memiliki induk bahan, harga asas, stok, dan identiti kewangan pelanggan. Magento memiliki penerangan, imejan, kategori, metadata SEO, ulasan, dan perdagangan. Kemudian kuatkuasakannya. Tolakan ERP setiap malam yang secara senyap menulis ganti teks tulisan tangan dan penerangan meta ialah pepijat paling melemahkan semangat dalam kategori ini: ia memusnahkan kerja sebenar secara senyap, dan pasukan SEO menemuinya berminggu-minggu kemudian.

Simpan jadual pemetaan yang eksplisit berkunci pada pengecam yang stabil dan bukan padanan rentetan pada SKU, kerana SKU ditukar nama dan ditukar huruf besar kecil. Putuskan apa yang berlaku kepada rekod yang wujud di satu pihak sahaja: dilangkau secara senyap, ditandakan dalam laporan, atau disekat daripada dijual. Kos tersilap dalam hal ini bukan sekadar perakaunan. Segmentasi, aliran troli terbengkalai, dan pemperibadian dalam laman yang dibina melalui EC Intelligence mewarisi apa jua yang dihasilkan integrasi itu, jadi pesanan yang tersegerak separuh muncul semula sebagai angka nilai sepanjang hayat yang salah dan kempen yang tersasar.

Kekerapan: kelompok berbanding hampir masa nyata bukan satu keputusan

Bertanya sama ada integrasi itu patut masa nyata atau kelompok ialah soalan yang salah, kerana jawapannya berbeza bagi setiap objek.

Dipacu peristiwa

Pesanan, pembatalan, perubahan penghantaran dan status, serta pergerakan stok pada barisan yang laju bergerak. Kos kelewatan di sini diukur dalam jualan berlebihan dan tiket sokongan.

Berjadual

Induk produk penuh, petikan stok penuh, muatan senarai harga, invois dan memo kredit. Berpura-pura operasi pukal ini ialah peristiwa menghasilkan puluhan ribu mesej dalam tetingkap malam yang ERP itu tidak pernah direka untuknya.

Hampir masa nyata ada kosnya, dan pasukan ERP yang membayarnya dalam bentuk pemprosesan antara muka, penguncian jadual, dan tetingkap kerja latar belakang. Persetujui volum bersama mereka sebelum mereka bentuk apa-apa. Sebuah kempen yang menetapkan semula harga puluhan ribu SKU pada tengah malam mesti tiba sebagai kelompok terkawal, bukan ribut mesej yang bersaing dengan penghantaran pesanan untuk kapasiti yang sama.

Penyelarasan: kerja yang kebanyakan integrasi tidak pernah bina

Setiap integrasi menghanyut. Anggaplah begitu, dan bina pengesannya dan bukan penafiannya. Asas yang boleh dipakai ialah perbandingan setiap malam bagi stok boleh dijual dan harga asas merentas katalog aktif, dengan perbezaan yang membetulkan sendiri dalam toleransi yang dipersetujui dan memberi makluman di luarnya. Tambah semakan peringkat pesanan setiap hari yang membandingkan kiraan dan nilai di kedua-dua belah pihak, menyenaraikan pesanan kedai tanpa dokumen ERP dan sebaliknya.

Hasilnya mesti satu laporan pendek yang dibaca oleh seorang yang dinamakan, bukan satu lagi fail log. Laporan yang biasanya kosong akan disedari apabila ia tidak kosong.

Mod kegagalan yang hanya muncul di bawah beban

Semua yang di atas benar pada volum biasa, dan sentiasa diuji pada volum biasa. Kegagalan yang menarik tiba semasa kempen, apabila kedalaman baris gilir membesar lebih cepat daripada kadar pekerja mengalirkannya dan penyegaran stok tersekat di belakang tolakan harga pukal. Uji beban integrasi itu, bukan hanya kedai dalam talian, dan putuskan lebih awal apa yang digugurkan apabila kapasiti kesuntukan. Kekerapan penyegaran stok biasanya kalah kepada penghantaran pesanan.

Disiplin berkaitan ialah memastikan ERP berada di luar laluan permintaan: tiada apa-apa dalam tambah ke troli, pembayaran, atau pembuatan pesanan yang patut menunggu sistem yang anda tidak kawal. Bridzia telah menyelenggara platform Adobe Commerce Guardian Malaysia lebih lapan tahun, menerusi pembaharuan yang meningkatkan prestasi laman sebanyak 200% dan menaikkan jualan sebanyak 10%, dan kelajuan halaman seperti itu tidak serasi dengan panggilan ERP segerak dalam laluan pelanggan.

Pasaran dalam talian menambah lapisan penyegerakan kedua, kerana Shopee, Lazada dan TikTok Shop masing-masing memegang pandangan tersendiri tentang stok dan pesanan. Itulah yang WOW Sync, teknologi penyegerakan pasaran dalam talian milik Bridzia sendiri, wujud untuk menyelesaikannya, dan satu catatan projek terdahulu menerangkan cara bahagian itu bergabung dengan inventori di kedai dan di gudang.

Apa yang sebenarnya menentukan sama ada ia bertahan

Pemilikan setiap medan, dipersetujui dan didokumenkan. Satu formula stok boleh dijual, dikira di satu tempat. Satu penulis bagi setiap medan harga. Penghantaran pesanan yang boleh diulang, berkunci pada rujukan luaran yang stabil. Percubaan semula yang dikelaskan kepada boleh cuba semula dan muktamad, dengan baris gilir surat mati yang dipantau seseorang. Kekerapan yang dipilih bagi setiap objek. Penyelarasan yang berjalan sejak hari pertama dan bukan ditambah selepas bulan buruk yang pertama.

Tiada satu pun daripadanya menarik, dan kesemuanya lebih murah diputuskan semasa peringkat seni bina berbanding semasa UAT. Integrasi ialah bahagian paling sukar dalam pembinaan Adobe Commerce untuk diubah setelah pesanan mengalir melaluinya.

Bridzia membina dan menyelenggara platform Adobe Commerce (Magento) dari Kuala Lumpur untuk jenama peruncitan dan FMCG di seluruh Asia, dengan lebih 100 projek disiapkan. Jika anda sedang merancang integrasi SAP, atau sedang mencari sebab integrasi sedia ada terus menghanyut, hubungi kami.