e-Con

Checkout Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
[ICT-2261] eCon standalone MAT model ontwikkelen

Testbestanden updaten voor:

- Herwerking van Winkelkarinfo. Materiaal en Kleur staan nu op winkelkarinfo en niet langer op winkelkarinfo diverse. Dit om uniformiteit na te streven. ITR zal dit ook aanpassen langs hun kant

    • -110
    • +110
    /development/integratietest/mat/mat-nabestelling-lbx-dubbele-sifonlade.txt
    • -99
    • +99
    /development/integratietest/mat/mat-nabestelling-lbx-binnenlade-glazenfront.txt
[ICT-2261] eCon standalone MAT model ontwikkelen

- Herwerking van Winkelkarinfo. Materiaal en Kleur staan nu op winkelkarinfo en niet langer op winkelkarinfo diverse. Dit om uniformiteit na te streven. ITR zal dit ook aanpassen langs hun kant

Merged revision(s) 3008 from development:

[ICT-2203] PM - TAX front voor LBX - oplossing voor "OudZwart" (Z8/Z9):

- Vertalingen voor KantenbandKleur Z9 - OudZwart - Zwart u999

........

Merged revision(s) 3008 from development:

[ICT-2203] PM - TAX front voor LBX - oplossing voor "OudZwart" (Z8/Z9):

- Vertalingen voor KantenbandKleur Z9 - OudZwart - Zwart u999

........

    • -0
    • +13
    /accept/models/tax/TAX Configurator,1.0.0.trl
Merged revision(s) 3007 from development:

[ICT-2203] PM - TAX front voor LBX - oplossing voor "OudZwart" (Z8/Z9):

- KantenbandKleur uitgebreid met OudZwart Z9 => visibility afhankelijk van CONFIG.Settings.KleurOudZwartToegelaten zoals bij LadeKleur OudZwart.

- Defaulting zodra LadeKleur OudZwart gekozen wordt uitgebreid met LadeBinnenKleur S en BodemKleur S en KantenbandKleur Z9.

- Constraint toegevoegd => Bij LadeKleur Z9 kunnen KantenbandKleuren anders dan OudZwart NIET

- Correctie Bepaling ItemId betreffende al dan niet bicolor bij LosseComponenten => enkel zijkanten kunnen bicolor zijn (naar analogie aanpassing code in Cache => GenerischProductBepaler)

........

    • too large
    /accept/models/tax/TAX Configurator,1.0.0.xml
[ICT-2203] PM - TAX front voor LBX - oplossing voor "OudZwart" (Z8/Z9):

- Vertalingen voor KantenbandKleur Z9 - OudZwart - Zwart u999

[ICT-2203] PM - TAX front voor LBX - oplossing voor "OudZwart" (Z8/Z9):

- KantenbandKleur uitgebreid met OudZwart Z9 => visibility afhankelijk van CONFIG.Settings.KleurOudZwartToegelaten zoals bij LadeKleur OudZwart.

- Defaulting zodra LadeKleur OudZwart gekozen wordt uitgebreid met LadeBinnenKleur S en BodemKleur S en KantenbandKleur Z9.

- Constraint toegevoegd => Bij LadeKleur Z9 kunnen KantenbandKleuren anders dan OudZwart NIET

- Correctie Bepaling ItemId betreffende al dan niet bicolor bij LosseComponenten => enkel zijkanten kunnen bicolor zijn (naar analogie aanpassing code in Cache => GenerischProductBepaler)

    • too large
    /development/models/tax/TAX Configurator,1.0.0.xml
Merged revision(s) 3004 from development:

[ICT-2203] PM - TAX front voor LBX - oplossing voor "OudZwart" (Z8/Z9):

- Toevoegen image OudZwart Z9 - Zwart u999 voor KantenbandKleur

........

    • binary
    /production/images/tax/KantenbandKleur/Z9.png
Merged revision(s) 3004 from development:

[ICT-2203] PM - TAX front voor LBX - oplossing voor "OudZwart" (Z8/Z9):

- Toevoegen image OudZwart Z9 - Zwart u999 voor KantenbandKleur

........

    • binary
    /accept/images/tax/KantenbandKleur/Z9.png
[ICT-2203] PM - TAX front voor LBX - oplossing voor "OudZwart" (Z8/Z9):

- Toevoegen image OudZwart Z9 - Zwart u999 voor KantenbandKleur

    • binary
    /development/images/tax/KantenbandKleur/Z9.png
[ICT-2261] eCon standalone MAT model ontwikkelen

Testbestanden updaten voor:

- Info diverse uitbreiden met informatie over bijhorende lade

    • -0
    • +110
    /development/integratietest/mat/mat-nabestelling-lbx-binnenlade-glazenfront.txt
[ICT-2261] eCon standalone MAT model ontwikkelen

- Info diverse uitbreiden met informatie over bijhorende lade

Merged revision(s) 2998-2999 from development:

[ICT-2261] eCon standalone MAT model ontwikkelen

- Door een voorgaand copy paste fouttje was de waarde 160 bij Z1 niet meer correct visible

........

[ICT-2261] eCon standalone MAT model ontwikkelen

- Door een voorgaand copy paste fouttje was de waarde 160 bij Z1 niet meer correct visible

........

Merged revision(s) 2998-2999 from development:

[ICT-2261] eCon standalone MAT model ontwikkelen

- Door een voorgaand copy paste fouttje was de waarde 160 bij Z1 niet meer correct visible

........

[ICT-2261] eCon standalone MAT model ontwikkelen

- Door een voorgaand copy paste fouttje was de waarde 160 bij Z1 niet meer correct visible

........

    • -1
    • +1
    /accept/models/mat/MAT Configurator,1.0.0.xml
[ICT-2261] eCon standalone MAT model ontwikkelen

- Door een voorgaand copy paste fouttje was de waarde 160 bij Z1 niet meer correct visible

[ICT-2261] eCon standalone MAT model ontwikkelen

- Door een voorgaand copy paste fouttje was de waarde 160 bij Z1 niet meer correct visible

Merged revision(s) 2993 from development:

[ICT-2506] Econ: Franse vertaling 'Sifonlade' aanpassen waar nodig

........

Merged revision(s) 2993 from development:

[ICT-2506] Econ: Franse vertaling 'Sifonlade' aanpassen waar nodig

........

    • -2
    • +2
    /accept/models/tbx/TBX Configurator,1.0.0.trl
Merged revision(s) 2991-2992 from development:

[ICT-2506] Econ: Franse vertaling 'Sifonlade' aanpassen waar nodig

........

[ICT-2506] Econ: Franse vertaling 'Sifonlade' aanpassen waar nodig

- Updaten testbestanden

........

Merged revision(s) 2991-2992 from development:

[ICT-2506] Econ: Franse vertaling 'Sifonlade' aanpassen waar nodig

........

[ICT-2506] Econ: Franse vertaling 'Sifonlade' aanpassen waar nodig

- Updaten testbestanden

........

    • -1
    • +1
    /accept/models/tax/TAX Configurator,1.0.0.trl
[ICT-2506] Econ: Franse vertaling 'Sifonlade' aanpassen waar nodig
[ICT-2506] Econ: Franse vertaling 'Sifonlade' aanpassen waar nodig

- Updaten testbestanden

[ICT-2506] Econ: Franse vertaling 'Sifonlade' aanpassen waar nodig
Merged revision(s) 2976 from development:

[ICT-2203] PM - TAX front voor LBX - oplossing voor "OudZwart" (Z8/Z9):

- Vertalingen voor Z9 - OudZwart - Zwart u999

........

Merged revision(s) 2988 from development:

[ICT-2203] PM - TAX front voor LBX - oplossing voor "OudZwart" (Z8/Z9):

- De valid voor OudZwart weer uit de rules gehaald => gaf in sommige gevallen ongewenst resultaat, waarbij config onterecht valid werd => waarschijnlijk door conflicen/overrides tussen rules enerzijds en contraints voor kleuren.

- In plaats daarvan constraint toegevoegd tussen LadeKleur OudZwart en ProductWijze anders dan FLBXEN LadeKleur OudZwart en VerpakkingType anders dan LosseComponenten.

- Defaulting voorzien voor ProductieWijze FLBX en VerpakkingType LosseComponenten zodra LadeKleur OudZwart gekozen wordt => anders iedere keer vervelende constraints-popup indien er al één van die kenmerken geselecteerd staat (op iets anders) zodra OudZwart gekozen wordt.

........

    • too large
    /accept/models/tax/TAX Configurator,1.0.0.xml
[ICT-2203] PM - TAX front voor LBX - oplossing voor "OudZwart" (Z8/Z9):

- De valid voor OudZwart weer uit de rules gehaald => gaf in sommige gevallen ongewenst resultaat, waarbij config onterecht valid werd => waarschijnlijk door conflicen/overrides tussen rules enerzijds en contraints voor kleuren.

- In plaats daarvan constraint toegevoegd tussen LadeKleur OudZwart en ProductWijze anders dan FLBXEN LadeKleur OudZwart en VerpakkingType anders dan LosseComponenten.

- Defaulting voorzien voor ProductieWijze FLBX en VerpakkingType LosseComponenten zodra LadeKleur OudZwart gekozen wordt => anders iedere keer vervelende constraints-popup indien er al één van die kenmerken geselecteerd staat (op iets anders) zodra OudZwart gekozen wordt.

    • too large
    /development/models/tax/TAX Configurator,1.0.0.xml
In m'n tweede ronde van het reviewen heb ik het antwoord zelf gevonden : de 2e parameter "$$$True" zet een test-kenmerk op, die triggert de method GeefTestEconConfiguratieArray() in de converter ze...

In m'n tweede ronde van het reviewen heb ik het antwoord zelf gevonden : de 2e parameter "$$$True" zet een test-kenmerk op, die triggert de method GeefTestEconConfiguratieArray() in de converter zelf.
Dus wat dat betreft is de hocus pocus voor mij (!) verklaard, maar de eerst-volgende die dit tegenkomt heeft wellicht hetzelfde probleem.
Mijn voorstel : het toevoegen van het "Test"-kenmerk wordt duidelijker als je dat meer expliciet maakt :
bvb. de impl en de 2e parameter "IsTestRequest As %Boolean = 0" weghalen uit de method GeefRequestMetKenmerken(), en in plaats daarvan het test-kenmerk hier toevoegen (eventueel via een extra private method) :

   #dim OCCKenmerkenRequest As WS.Vhisie4.OCC.GeefNaarEconGeconverteerdeKenmerkenRequest = ..GeefRequestMetKenmerken(4, )
   Do ..VoegToeBlumKenmerkTest(OCCKenmerkenRequest.BlumKenmerken)

private method VoegToeBlumKenmerkTest(BlumKenmerken As %ListOfObjects) [ Private ]
{
	Set Kenmerk = ##class(WS.Vhisie4.OCC.dto.Kenmerk).%New()
	Set Kenmerk.Name = "test"
	Do BlumKenmerken.Insert(Kenmerk)
}
Methodnaam of implementatie verduidelijken, want ik begrijp niet waar die resultaten vandaan komen; o.a. LadeDiepte 500 en Corpusbreedte600. Hocus pocus? ... Zie meteen hieronder voor t vervolg.

Methodnaam of implementatie verduidelijken, want ik begrijp niet waar die resultaten vandaan komen; o.a. LadeDiepte 500 en Corpusbreedte600.
Hocus pocus?
... Zie meteen hieronder voor t vervolg.

Copy-paste (2x hetzelfde)

Copy-paste (2x hetzelfde)