Checkout Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
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
    • +1
    ./Converter/AxProductKenmerkenConverter.cls.xml
  1. … 14 more files in changeset.
Testje bijgezet als AttrVsAdminProdNr niet SalesPriceBOM is => dan moet er betreffende de ProductIdRecycleerder niets gebeuren.

Testje bijgezet als AttrVsAdminProdNr niet SalesPriceBOM is => dan moet er betreffende de ProductIdRecycleerder niets gebeuren.

Ik vond dat nogal overkill, omdat die list dan amper een codelijn of 6 later alweer omgezet zou moeten worden naar een delimited string. Moest de omzetting naar delimited string in een andere metho...

Ik vond dat nogal overkill, omdat die list dan amper een codelijn of 6 later alweer omgezet zou moeten worden naar een delimited string. Moest de omzetting naar delimited string in een andere method gebeuren, dan zou ik het zeker gedaan hebben

Ook zoals aan telefoon besproken... het gaat over de LadeVariant zoals gekend in AX, waarvoor overal in de BOMBOL de AXimpl gebruikt wordt.

Ook zoals aan telefoon besproken... het gaat over de LadeVariant zoals gekend in AX, waarvoor overal in de BOMBOL de AXimpl gebruikt wordt.

Zoals besproken aan de telefoon: Dat Request komt in de BOMBOL-interface ook al binnen als parameter, dus de afhankelijkheid is sowieso al een feit. Bovendien wordt er 1 laagje hoger ook een andere...

Zoals besproken aan de telefoon: Dat Request komt in de BOMBOL-interface ook al binnen als parameter, dus de afhankelijkheid is sowieso al een feit. Bovendien wordt er 1 laagje hoger ook een andere property van uitgelezen

testje(s) voor de andere gevallen?

testje(s) voor de andere gevallen?

ikzelf probeer constructies als deze meestal te vermijden omdat het om de zoveel tijd wel eens kan leiden naar een rariteit met die delimiter. Misschien beter om een list te gebruiken? Kunt ge gewo...

ikzelf probeer constructies als deze meestal te vermijden omdat het om de zoveel tijd wel eens kan leiden naar een rariteit met die delimiter. Misschien beter om een list te gebruiken? Kunt ge gewoon op adden indien nodig. Een list kan daarna 'gewoon' in een delimited string omgezet worden indien nodig.

minor nitpicking: ik las dit als een Event "OnJadajada" en het duurde toch een fractie van een seconde voor ik doorhad dat dat niet echt logisch zou zijn indeze context. Een kleine "B" was misschie...

minor nitpicking: ik las dit als een Event "OnJadajada" en het duurde toch een fractie van een seconde voor ik doorhad dat dat niet echt logisch zou zijn indeze context. Een kleine "B" was misschien logische geweest. Nogmaals: kommaneuken hoor

een beetje in de trand van de vorige opmerking: zou het niet properder zijn om de DOM....LadeVariant te gebruiken (qua hiërarchie hé). Je gaat dan wel een 'converter' moeten opzetten die de AX-vari...

een beetje in de trand van de vorige opmerking: zou het niet properder zijn om de DOM....LadeVariant te gebruiken (qua hiërarchie hé). Je gaat dan wel een 'converter' moeten opzetten die de AX-variant omzet naar een DOM-variant, maar daar kan de LadeVariantBepaler zich mee bezighouden. Op die manier verdwijnt de dependency op AXimpl.* package

Van deze request wordt enkel Request.Attribute gebruikt. Het zou beter zijn om die attribute als parameter mee te geven, anders introduceer je een (extra?) afhankelijkheid tss WSimpl en AXif packages.

Van deze request wordt enkel Request.Attribute gebruikt. Het zou beter zijn om die attribute als parameter mee te geven, anders introduceer je een (extra?) afhankelijkheid tss WSimpl en AXif packages.

[ICT-2090] [rvTVE] PM: Maatwerk: BOMBOL VHIP481: Soms opvragen zonder product aan te maken:
[ICT-2090] [rvTVE] PM: Maatwerk: BOMBOL VHIP481: Soms opvragen zonder product aan te maken:
[ICT-2090] [rvTVE] PM: Maatwerk: BOMBOL VHIP481: Soms opvragen zonder product aan te maken:

- BestaatProduct toegevoegd => vergeten mock en fake mee te committen vorige keer

    • -0
    • +6
    ./ProductVolgensAxAttribuutBepaler/ProductIdRecycleerder.cls.xml
  1. … 1 more file in changeset.
[ICT-2090] [rvTVE] PM: Maatwerk: BOMBOL VHIP481: Soms opvragen zonder product aan te maken:

- GeefTeRecyclerenProductId in ProductIdRecycleerder geeft nu eerstvolgend ProductId terug uit juiste range

- Implementatie GeefProductIdVrij

- In RequestConverter => al voorlopig check of het over juist case gaat en in dat geval voorziening in comment om GeefProductIdVrij op te roepen en ProductId na afloop weer vrij te geven

    • -0
    • +6
    ./ProductVolgensAxAttribuutBepaler/ProductIdRecycleerder.cls.xml
  1. … 3 more files in changeset.
[ICT-2090] [rvTVE] PM: Maatwerk: BOMBOL VHIP481: Soms opvragen zonder product aan te maken:

- Eerste opzet ProductIdRecycleerder => Geeft voorlopig altijd lege string terug als ProductId.

- Al ineens mockable gemaakt voor testing => TODO

- Wel al aantal voorzieningen:

=> 4 ranges (LBX, MVX, TAX en TBX) gedefinieerd als komma seperated strings => voorziet in flexibele aanpassing en uitbreiding van ranges

=> Controle of initieel ranges wel effectief vrij zijn (per LadeType of ineens alle ranges) => via BestaatProduct op ProductApi => OPGELET: Manueel via PuTTy in gang te zetten => Volgt misschien nog een deployklaske voor

=> Persistering van 4 ranges in dedicated Global ^ProductIdRecycle => Om bij te houden welke ProductId's op dat moment in gebruik zijn => OPGELET: Manueel via PuTTy in gang te zetten => Volgt misschien nog een deployklaske voor

=> Dit laatste kan ook gebruikt worden om, na indienstname, alle ProductId's (per LadeType of ineens alle ranges) weer volledig vrij te geven => USE WITH CAUTION

    • -0
    • +41
    ./ProductVolgensAxAttribuutBepaler/ProductIdRecycleerder.cls.xml
  1. … 2 more files 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
    • +1
    ./Converter/AxProductKenmerkenConverter.cls.xml
  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.