vervoerders foutmelding "Bereiken overlappen"

[Frevab]

Ik krijg bij alle vervoerders die ik aangemaakt hebt en die meerdere gewichtsstappen hebben de melding "Bereiken overlappen " als ik de verzendtarieven wil wijzigen.

k heb de tabel in de database gedownload en in Excel bekeken maar daar zie ik niets geks in. Bij de ene vervoerder is t/m gewicht gelijk aan vanaf gewicht van de volgende stap maar bij de andere vervoerder weer niet dus daar kan het niet aan liggen. Bij het invoeren gaf hij daar geen foutmelding op.

Waar kan dit aan liggen en heeft iemand anders ook deze ervaring ?

[Inform-All]

Kunt u misschien iets uitgebreidere details van de vervoerders met ons delen?
Daarnaast, is het niet mogelijk om meer dan 200 vervoerders actief te hebben. 
(welke PS versie gebruikt u?)

 

[Frevab]

Ik heb een 5 tal vervoerders aangemaaktin  versie 1.7.2.4: PostNL briefpost, PostNL pakketpost, PostNL afhaallocatie, DPD en afhalen.

Bij PostNL briefpost, PostNL pakketpost en DPD zit er een tabel aan vast met de diverse gewichtsstappen/kolommen. Bij afhaallocatie en afhalen is er maar één kolom (één prijs voor een wat breeder gewichts bereik).

De 3 eerste genoemde vervoerder (die met meerdere kolommen) geven nu een foutmedling en daar kan ik alleen het eerste tabblad laden en wijzigen, als ik doorga naar stap 2 (waar de tarieven staan) komt de fout "bereiken overlappen" en blijft hij dus bij het eerste tabblad.

Ik heb de diverse tabellen uit de database gehaald en in Excel bekeken en daar komt ik wer wat vreemde zaken tegen.  De shop is gemigreerd en de vervoerders die ik ook aangemaakt hebt maar niet meeractief waren zijn wel meegekomen naar de nieuwe database. Op zich geen problem maar alleen vervuilend. Daarnaast valt mij op de bij een aantal vervoerder de gewichtsstappen er wel staan maar ook een gewichtsstap zonder vanaf t/m gewicht dus hoe die daar is gekomen weet ik niet. Wellicht dat dat zo hoort? 

Wat mij wel opvalt is dat er ook problemen zijn met het weergeven van de vervoerders die een error geven in de cart.

Als ik een nieuwe vervoerder aanmaak met 2 gewichtskolommen dan laat hij die wel zien en ik kan deze ook probleemloos aanpassen. Kennelijk is er iets gedurende de tijd gewijzigd waardoor de error ontstaat.

Ik heb even met Notepad+ in alle PS mappen gezocht op de engelse bewoording van de error en dan zie ik dat hij bij maar een .tpl bestand voorkomt. Ik ben niet kundig op het gebied van de coding maar wil wel graag weten waardoor de fout gegenereerd wordt.

Ik heb nog een default versie draaien in een andere map in de root en ik ga nog eens even kijken wat die in  de database produceert.

[Frevab]

Ik heb de diverse tabellen in de database opgeschoond die met vervoerders te maken hebben en oude regels van vervoerders die niet meer gebrukt werden verwijdert.

Hierna opnieuw getest maar de foutmelding blijft het zelfde en verzendtarieven zijn bij 3 van de 5 vervoerders niet te wijzigen.

 

Debug mode geeft verder geen foutmelding.

Ik ben een merchant en geen web programmeur dus kan de programma code niet lezen/begrijpen maar ik heb wel via Notepad++ gezocht waar deze fout melding vermeldt staat en kom dan bij "js\admin\carrier_wizard.js".

Wie kan mij uitleggen wat de voorwaarden zijn om deze fout melding te generen:

Vanaf regel 500 staat daar  (volledige carrier_wizard.js in bijlage)

function validateRange(index)
{
    $('#carrier_wizard .actionBar a.btn').removeClass('disabled');
    $('.wizard_error').remove();
    //reset error css
    $('tr.range_sup td input:text').closest('div.input-group').removeClass('has-error');
    $('tr.range_inf td input:text').closest('div.input-group').removeClass('has-error');

    var is_valid = true;
    range_sup = parseFloat($('tr.range_sup td:eq('+index+')').find('div.input-group input:text').val().trim());
    range_inf = parseFloat($('tr.range_inf td:eq('+index+')').find('div.input-group input:text').val().trim());

    if (isNaN(range_sup) || range_sup.length === 0)
    {
        $('tr.range_sup td:eq('+index+')').find('div.input-group input:text').closest('div.input-group').addClass('has-error');
        is_valid = false;
        displayError([invalid_range], $("#carrier_wizard").smartWizard('currentStep'));
    }
    else if (is_valid && (isNaN(range_inf) || range_inf.length === 0))
    {
        $('tr.range_inf td:eq('+index+')').find('div.input-group input:text').closest('div.input-group').addClass('has-error');
        is_valid = false;
        displayError([invalid_range], $("#carrier_wizard").smartWizard('currentStep'));
    }
    else if (is_valid && range_inf >= range_sup)
    {
        $('tr.range_sup td:eq('+index+')').find('div.input-group input:text').closest('div.input-group').addClass('has-error');
        $('tr.range_inf td:eq('+index+')').find('div.input-group input:text').closest('div.input-group').addClass('has-error');
        is_valid = false;
        displayError([invalid_range], $("#carrier_wizard").smartWizard('currentStep'));
    }
    else if (is_valid && index > 2) //check range only if it's not the first range
    {
        $('tr.range_sup td').not('.range_type, .range_sign, tr.range_sup td:last').each(function ()
        {
            if ($('tr.fees_all td:eq('+index+')').hasClass('validated'))
            {
                is_valid = false;
                curent_index = $(this).index();

                current_sup = $(this).find('div.input-group input').val();
                current_inf = $('tr.range_inf td:eq('+curent_index+') input').val();

                if ($('tr.range_inf td:eq('+curent_index+1+') input').length)
                    next_inf = $('tr.range_inf td:eq('+curent_index+1+') input').val();
                else
                    next_inf = false;

                //check if range already exist
                //check if ranges is overlapping
                if ((range_sup != current_sup && range_inf != current_inf) && ((range_sup > current_sup || range_sup <= current_inf) && (range_inf < current_inf || range_inf >= current_sup)))
                    is_valid = true;
            }

        });

        if (!is_valid)
        {
            $('tr.range_sup td:eq('+index+')').find('div.input-group input:text').closest('div.input-group').addClass('has-error');
            $('tr.range_inf td:eq('+index+')').find('div.input-group input:text').closest('div.input-group').addClass('has-error');
            displayError([range_is_overlapping], $("#carrier_wizard").smartWizard('currentStep'));
        }
        else
            isOverlapping();
    }
    return is_valid;
}

 

In de tabel ps_id_range-weight zie ik verder geen gekke dingen. De carriers die de fout geven zijn 81, 86 en 88. Carriers 87 en 89 geven geen fout en zijn ook op tabblad 2, 3 en 4 te wijzigen en op te slaan.

Carrier 93 heb ik na het ontstaan van de fout melding aangemaakt en die geeft gene fout en is ook prima te wijzigen.

 

 

 

Bij DB tabel ps_id_range_price zie ik nu voor het eerst carrier 94 die ik niet aangemaakt heb en ook op het BO scherm Vervoerders niet voorkomt.

Ook in tabel ps_delivery komt id-carrier 94 voor met twee regels. Niet door mij aangemaakt.

Ik gebruik wel een verzendmodule van SendCloud met een API koppeling maar dat is alleen voor id-carrier 87 (afhaalpunt) en via de API kunnen ze de ordergegeven inlezen voor het aanmaken van PostNL verzendlabels.

Ook in tabel ps_carrier komt id_carrier 94 nou opeens voor met de vermelding sendcloud.

Op zich lijkt mij het niet logisch dat ik de foutmelding krijg bij 3 carriers (81-86-88) en juist niet bij 87 (SendCloud) en de spook id_carrier 94 (SendCloud)

Iemand een idee?

 

carrier_wizard.js

[Frevab]

De herkomst van de nieuwe id_carrier 94 is inmiddels duidelijk. Ik heb gisteren een test carrier bewerkt en deze werd door PS zelf opnieuw aangemaakt en de oorspronkelijk als delete aangemerkt maar blijft wel in de tabel staan.  Dus kennelijk is het zo als je iets aan een carrier gewijzigd wordt deze automatisch door PS als nieuwe carrier wordt toegevoegd en de "oude" naar delete gezet wordt maar wel in de DB tabel blijft staan maar niet meer in het BO carrier overzicht te zien is (omdat hij gedelete is).

 

Probleem met de Overlapping Range is er nog steeds. Hoop dat iemand mij daarmee kan helpen.

[Frevab]

Niemand enig idee?

[veldepatrick]

Ik weet niet of het iemand helpt, maar ik heb gewoon de oude vervoerder verwijderd en een nieuwe aangemaakt. Dit keer niet op basis van prijs bereik, maar gewicht. Nu werkt alles zoals het hoort en is de vervoerder ook te wijzigen.

[Vincent Comm.On]

Ik had net de zelfde issue. Het heeft er mee te maken dat bij je bereik instellingen de waardes van je prijsverandering niet het zelfde mogen zijn.

Ik had bijvoorbeeld:

• 0 - 5.0000 €5,00 verzendkosten 
• 5.0000 - 30.0000 .......

Dit mag niet je moet dan 0 - 4.99999 en 5.0000 - 30.0000 als waardes gebruiken. Het beste is om de zelfde verzendmethode opnieuw aan te maken en de oude te verwijderen.

Edited February 28, 2020 by Vincent Comm.On
Extra explaination (see edit history)