Checkout Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
[ICT-3333] [rvTVE] PM-BIDI: TAX: LosseComponenten updaten bodems en zijkanten:

- Voor losse componenten mag er in de BezwarenControleur niet gecheckt worden op historieken. Dit is uitzonderlijk nodig omdat het over vaste producten gaat die normaliter nooit geüpdated worden, wat nu wèl moet gebeuren om de "nieuwe" HoogteVerstelling-bouwtenen erbij te krijgen. Er bleken historieken in de weg te zitten. De noodzaak tot correcte bouwstenen en prijzen overruled de historieken.

  1. … 2 more files in changeset.
Ook een klein stukje in Econ! (zie svn)

Ook een klein stukje in Econ! (zie svn)

[ICT-1693] TAXEB1 - PM: Maatwerk: BevatGeleiderBevestigingSchroeven = True indien Alpnach:
[ICT-1693] TAXEB1 - PM: Maatwerk: BevatGeleiderBevestigingSchroeven = True indien Alpnach:
[ICT-1693][rvWV] TAXEB1 - PM: Maatwerk: BevatGeleiderBevestigingSchroeven = True indien Alpnach:

- BevatGeleiderBevestigingSchroeven toegevoegd in nodige dto'kes en kenmerkensets, alsook utils-kenmerkensets

- Conversie van BevatGeleiderBevestigingSchroeven voorzien waar nodig

- Vorige voorlopige change weer verwijderd, waarin BevatGeleiderBevestigingSchroeven hardcoded voor Alpnach op true gezet werd => wordt nu gezet in Econ en proper doorgegeven via de IngegevenKenmerken

  1. … 14 more files in changeset.
ik zou onderstaande private method op de DOM.VKP.impl.LeverAdresRepository zetten. Dan kan ie hier proper uitgemocked worden. Die repo bevat ook een hoop testen die gemakkelijk aangepast kunnen wor...

ik zou onderstaande private method op de DOM.VKP.impl.LeverAdresRepository zetten. Dan kan ie hier proper uitgemocked worden. Die repo bevat ook een hoop testen die gemakkelijk aangepast kunnen worden om onderstaand gedrag te testen.

't is wel zo dat die Repository geen pure repo is, maar ook functionaliteit heeft die eigenlijk in een bovenliggende service zouden moeten zitten (maar dat is een ander verhaal)

Misschien kan de onderstaande functionaliteit dan ook vervangen worden door iets als in BestaatViaAXLeverAdresIdEnKlantNummer, maar dan met de query SELECT count(ID) from Derde_Klant.LevAdres where Klant = ? (zonder de Ax-dingen)

[ICT-2246] [rvTVE] Correctie loggingniveau betreffende LeverAdressen op Klant en BezwaarGevonden in...
[ICT-2246] [rvTVE] Correctie loggingniveau betreffende LeverAdressen op Klant en BezwaarGevonden in...
[ICT-2246] [rvTVE] Correctie loggingniveau betreffende LeverAdressen op Klant en BezwaarGevonden in ProductUpdater:

- I.g.v. HeeftBezwaarVoorProductDelete wordt nu een Warning gelogd i.p.v. een Error

  1. … 1 more file in changeset.
[ICT] CalculatedProduct - BOMBOL - ProductUpdater:

- Als er bezwaren gevonden zijn voor het updaten van een product, dan wordt dit voortaan niet meer gemaild naar ICT_Meldingen, maar enkel nog gelogd

- P.s.: Er wordt, indien nodig, nog wel een mail gestuurd naar Halux, rechtstreeks vanuit de code in WSimpl.AX.CalculatedProduct.ProductVolgensAxAttribuutBepaler.OrderService.ToeleveringService

  1. … 1 more file in changeset.
[ICT-1693] TAXEB1 - PM: Maatwerk: BevatGeleiderBevestigingSchroeven = True indien Alpnach:

- CustAccount wordt nu als 2e parameter mee doorgegeven aan de AxProductKenmerkenConverter

- Indien TAX en IsAlpnach => BevatGeleiderBevestigingSchroeven = True => Indien rechtstreekse klant = OK, via Personality SFS staat klaar maar wacht op voorziening PersonalityId (unimplemented in BOMBOL)

  1. … 4 more files in changeset.
Telegramstijl, omdat ze anders te lang worden en de variaties nu eenmaal soms ingewikkeld zijnhttp://subversion02.vanhoecke.be/static/ogdo0b/2static/images/wiki/icons/emoticons/wink.gif

Telegramstijl, omdat ze anders te lang worden en de variaties nu eenmaal soms ingewikkeld zijn

Idem reply hierboven.

Idem reply hierboven.

Zoals besproken... Dit ging over de property-namen, maar... toch liever niet. In de properties kunnen soms mocks, soms stubs gestoken worden, afhankelijk van wat de UnitTest nodig heeft.

Zoals besproken... Dit ging over de property-namen, maar... toch liever niet. In de properties kunnen soms mocks, soms stubs gestoken worden, afhankelijk van wat de UnitTest nodig heeft.

Done!

Done!

Done

Done

Done! (smartass http://subversion02.vanhoecke.be/static/ogdo0b/2static/images/wiki/icons/emoticons/wink.gif )

Done! (smartass )

Done!

Done!

Done, maar staat momenteel al nieuwe openstaande wijziging op die klasse, die nog niet gecommit mag worden, dus komt daarna wel.

Done, maar staat momenteel al nieuwe openstaande wijziging op die klasse, die nog niet gecommit mag worden, dus komt daarna wel.

Done, maar staat momenteel al nieuwe openstaande wijziging op die klasse, die nog niet gecommit mag worden, dus komt daarna wel.

Done, maar staat momenteel al nieuwe openstaande wijziging op die klasse, die nog niet gecommit mag worden, dus komt daarna wel.

Done en done en done! http://subversion02.vanhoecke.be/static/ogdo0b/2static/images/wiki/icons/emoticons/smile.gif

Done en done en done!

Normaal binnen de scope blijven, ik weet het, maar ik dacht de while op deze manier zo proper en leesbaar mogelijk te houden. Uiteindelijk wordt elk van die dim'ekes toch in die while gebruikt en o...

Normaal binnen de scope blijven, ik weet het, maar ik dacht de while op deze manier zo proper en leesbaar mogelijk te houden. Uiteindelijk wordt elk van die dim'ekes toch in die while gebruikt en omhelst die while de volledige method.

Denk het niet. Nu krijgt ge alle OrderLijnIterators netjes op een rijtje via code completion. Eentje is dan de volledige, sommige zijn "via" dit, andere "via" dat, ...

Denk het niet. Nu krijgt ge alle OrderLijnIterators netjes op een rijtje via code completion. Eentje is dan de volledige, sommige zijn "via" dit, andere "via" dat, ...

Had ik al aangepast inmiddels, zit al in volgende review http://subversion02.vanhoecke.be/static/ogdo0b/2static/images/wiki/icons/emoticons/wink.gif

Had ik al aangepast inmiddels, zit al in volgende review

test namen zeggen niet duidelijk wat er getest wordt.

test namen zeggen niet duidelijk wat er getest wordt.

(Is bestaande code natuurlijk) hoeft geen lokale var te zijn. mag rechtstreeks op ..ProductService(Mock)

(Is bestaande code natuurlijk) hoeft geen lokale var te zijn. mag rechtstreeks op ..ProductService(Mock)