Magento Sipariş Numarası Sorunu


9

Magento'daki Sipariş Numarasıyla ilgili garip bir sorunum var.

Son zamanlarda web siteme bir sipariş verildiğinde Sipariş numarası geldi 100000350, İdeal olarak 100000370önceki sipariş numaralarım gibi olmalı 100000369ve 100000367. Bunun için aşağıdaki ekran görüntüsünü ekledim

Sipariş Numarası Ekran Görüntüsü

Ayrıca, hata günlüklerini kontrol ettim ancak herhangi bir giriş bulamadım. Bunun için ödeme ağ geçidi olarak SagePay ve PayPal kullanıyoruz.

Birisi bana bu konuda rehberlik edebilir mi?


Ben açıkça bir sorun ortaya çıkacak sipariş taht's y ile ilgili herhangi bir modül yüklediğiniz görebilirsiniz,
Keyul Shah

Siparişle ilgili bir modül yoktur .. Kullandığımız tek üçüncü taraf modülü Ebizmarts_SagePay, Mass_Product_Relater, TBT_Enhancegrid ve Sphinix Search
Dexter

1
Büyük bir sorun, müşteri hesabına sahip biri, ödeme için gönderdiği noktaya kadar neredeyse bir siparişi tamamladı, bir Müşteri Siparişi numarası atandı ve daha sonra bir süre için sepeti terk etti. Her zaman olur ... Terk etmek yerine emri, tebrikleri, tamamlanmış emri aldınız.
Fiasco Labs

Sanırım sorum yoktu
Dexter

1
@huzefam - Lütfen bunu Magento tasarım ekibine götürün veya tamamlanmış Magento SO'da ERP'niz için kapattığınız kendi seri otonum sütununuzu oluşturun. Evet, denetim perspektifinden, eksik fatura numaraları varsa, hanky-panky olduğunu anlıyorum. Magento, tüm siparişlerin geçerli olmadığı fikrini almış gibi görünüyor, bu nedenle eksik SO sayıları önemli değil. Ayrıca, bazı muhasebe sistemlerinin, hükümet yargı yetkilerinin Satış Siparişleri konusunda aynı şekilde hissettiğini ve geçersiz siparişleri tam bir seri sırada gösteren bir denetim izi olmasını beklediğini de anlıyorum.
Fiasco Labs

Yanıtlar:


28

İlk kez sıra numarasının dışında kaldığımda, ne olduğunu anlayana kadar sürpriz ve bazı dezavantajlarımız vardı. Magento'nun Müşteri Siparişi numaralarını nasıl tahsis ettiği ile ilgilidir.

Bunun gibi bir sıra dışı olması, mevcut tahsis edilen numaralardan önce ve bir ay veya daha eski olması tamamen normaldir. Bunun sırrı, belirli bir kritik aşamadan sonra siparişi tamamlamayan, geri gelen, giriş yapan ve sonunda satın almaya karar veren giriş yapmış bir müşteri olmasıydı.

Tahsis edilen Müşteri Siparişi numarasına sahip fiyat teklifi Müşteri Siparişi numarası için bu numarayı kullanır.

Şimdi açıklama için.

Magento sipariş süreci, sepete ilk kez bir şey eklendiğinde bir fiyat teklifi oluşturur.

  • Konuk müşteriler için, bu teklif oturumları zaman aşımına uğramadığı sürece devam eder, bu noktada veritabanında bulunur, ancak konuk müşteri tarafından kurtarılamaz.
  • Kayıtlı bir müşteri oturum açtığında, alışveriş sepeti teklifi müşteri kimliğini atar, böylece müşteri, müşteri tarafından boşaltılmadığı sürece devam eder ve hesapta oturum açarak kayıtlı müşteri tarafından alınabilir.

Bu noktada, teklif yalnızca potansiyel bir Müşteri Siparişidir . Atanmış bir numarası yoktur, çünkü müşteri bunun için ödeme yapmayı taahhüt etmez.

Müşteri ödeme yapmak için Devam Et düğmesini tıkladığında :

  • sepete başlamadan önce giriş yapın
  • ya da giriş yapmamışlarsa, kayıt olmak ya da misafir olarak çıkış yapmak isteyip istemediklerini sordu.

Aşağıdakiler önemli bir nokta: Alışveriş sepetine kaydolmayı seçen müşteriler sipariş tamamlanana kadar misafir müşteri olarak değerlendirilir ve hesap oluşturulduklarında ve giriş yaptıkları başarı sayfasına ulaşırlar. sipariş tamamlanmazsa ve bir başarı sayfası görüntülenirse, oturum zaman aşımı sepeti kaybıyla konuk müşteri teklifi kalır .

Kredi kartı siparişinde, Sipariş Ver düğmesine tıklandığında aşağıdakiler gerçekleşir .

  • Kredi kartı bilgileri, fatura adresi bilgileri, alışveriş sepeti toplamları ve sipariş bilgileri birleştirilir
  • Bu teklif için bir Müşteri Siparişi numarası atanır ( sütundaki sales_flat_quotetablo reserved_order_id)
  • Veri paketi, siparişin ödenmesi için fonların yetkilendirilmesi / sınırlandırılması için kredi kartı ağ geçidine gönderilir.
  • Kredi sepeti işlemcisi geri dönüyor:
    • Ya bir fon yetki / yakalama uygun işlem bilgileri ile kaydedilecek
    • veya yetkilendirme / yakalamanın neden reddedildiğine ilişkin uygun bilgilerle ödemenin reddedilmesi.
  • Başarılı bir yetkilendirme / yakalama ile teklif bir Müşteri Siparişine dönüştürülür ve bu bir alışveriş sepeti kaydıysa müşteri hesabı oluşturulur.

Kredi kartı işlemi herhangi bir müşteri için kredi kartı ödeme ağ geçidi tarafından reddedilirse ve bir sonraki müşteri başarılı bir sipariş verirse , reddedilen ödeme Müşteri Siparişine ayrılmış bir Müşteri Siparişi numarası atandığı için Müşteri Siparişi numarasında bir atlama olur . ve aşağıdaki başarılı Müşteri Siparişine bir sonraki kullanılabilir numara atanır.

Oturum zaman aşımını aşan konuk arabaları (misafir siparişleri ve alışveriş sepeti müşterilerindeki başarısız kayıt) için, bu ayrılmış Müşteri Siparişi numarası oturumun süresi dolduğunda Müşteri Siparişi sırasında boşluk bırakarak kaybolacaktır .

Devam Et Düğmesini tıklamadan önce giriş yapan müşteriler için fiyat teklifine bir müşteri kimliği atanır, bu nedenle sipariş vermeyi denediğinde ve reddedildiğini tespit ederse, geri dönebilir, giriş yapabilir, alışveriş sepetinin hala içeriği olduğunu ve sipariş, bazen çok daha sonra (bugüne kadarki en uzun dört aydı). Fiyat teklifi, atanan ayrılmış Müşteri Siparişi numarasını kullanacak ve Müşteri Siparişi yönetimi ekranınızda gösterilen sıra dışı Müşteri Siparişi numarasına yol açacaktır .


Kontrol amacıyla, ödeme yöntemini seçip nihayet tarayıcıyı kapatarak (siteyi açan ilk bilgisayar + ödeme) kasada sıkışmış gibi davrandım. ve bu arada ikinci bilgisayar siparişini tamamladı (sonraki kimlik artışını almalı). Sonuç, sayının üzerinden atlamamasıdır. Bu şekilde çalışsaydı, sipariş 10 ile sipariş 11 arasına kullanılmayan bir kimlik eklerdi. Bilgilerinize göre, tam olarak belirttiğiniz şeyi doğrulamaya ve yapmaya çalıştım, ancak çıktı vermiyor.
Siva

Bunun yerine, bir müşteri Ödeme Ağ Geçidinde başarısız olursa, ödeme beklemede veya iptal edilmiş olarak görünür ve sipariş, ödemenin son bölümünde hiç görünmeyecek şekilde başarısız olursa (ve yalnızca sıra). Şimdi, bununla kafam karıştı. Lütfen sipariş numarasının neden rastgele atladığını anlamama yardımcı olun. Teşekkürler
Siva

Büyük Açıklama.
Wolfack

2

Aynı sorunla karşı karşıya kaldım ama sadece sunucu büyük miktarda yük ile vuruldu. Bu sorun, teklif sırasına dönüştürülürken db kilit durumuna geçer nedeniyle oluşur. Daha fazla incelemede, sorunun sales_flat_order tablosuna eklendikten hemen sonra işlem içindeki sales_flat_order_grid tablosuna yazmaya çalıştığıydı. Eşzamanlı sorgularla kilitli çarpışmalara neden oldu. Asıl çözüm, sales_flat_order_grid öğelerini işlemin dışına taşımaktır.

Bağlantı sorunu anlamama yardımcı oldu

Yama benim için sorunu çözdü.

_AfterSave işlevini Mage_Sales_Model_Abstract'tan kaldırmanız ve

public function afterCommitCallback(){
    if (!$this->getForceUpdateGridRecords()) {
         $this->_getResource()->updateGridRecords($this->getId());
     }
    parent::afterCommitCallback();
}

Sorunu sizin için çözüp çözmediğini bana bildirin.


Shaily tarafından söylendiği gibi bu yöntemi deneyen var mı?
Siva

0

Emin değilim, ama bu sorununuzu çözebilir:

Düşündüğüm kadarıyla, bir şey masanızı rahatsız etmiş olabilir eav_entity_store. Bir sonraki artım_kimliği ile ilgili bilgileri içerir, yani sipariş_kimliği kullanılır. Magento sisteminizdeki bazı modül veya kodlar değişmiş olabilir.

Bu tabloyu açın ve increment_last_id sütununu son sipariş kimliğinizle güncelleyin. Dikkatli olun, o mutlaka sadece gitmek için artım id en başkalarının vb faturanın, sevkiyat yanı gibi içerdiği eav_entity_typesmasa ve ne olduğunu görmek entity_type_idiçin sales/order(sütununda entity_model). Benim magento, onun 5. Yani şimdi eav_entity_storetabloya gidin ve sadece entity_type_id5 olan satır için increment_id güncelleyin. Doğrudan phpmyadmin ile güncelleyebilir veya gibi sorgu çalıştırabilirsiniz,

update eav_entity_store set increment_last_id = 'your_last_order_id' where entity_type_id = 5; 

Lütfen sipariş 5 için eflatunumda entity_type_id olduğunu unutmayın

Sorununuzun birçok nedeni olabilir, ancak bunun sorununuzu çözebileceğini düşünüyorum.


Teşekkürler .. ama zaten tablo kontrol ve doğru artış kimliği var
Dexter

yönetici satışlarında maksimum (en son olmayan) sipariş kimliğiniz nedir -> siparişler? Söylediğim tabloya bu değeri koyun .. bir test siparişi verin ve kontrol edin ..
Pradeep
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.