• Inloggen
  • nl-NLen-USde-DEzh-CN

Archief Request For Changes (RFC)

De tabel hieronder bevat een overzicht met alle RFC's. Je kunt deze lijst exporteren in Excel ().

Zelf een RFC indienen? Stuur dan een mail aan RFC@floricode.com.

Archief Request For Changes (RFC)

Back
Nr 973
Titel Verbeteringen CC VMP mbt Pricing
Categorie CC VMP
Omschrijving

V.w.b. Pricing structuren zijn er twee problemen:

Als er interpretatie verschillen zijn tussen twee partijen (=SL’s), dan heeft dit vaak met Pricing en/of Packing te maken. Dus puur de vraag “Wat koop ik en wat kost het”. Dit zou m.b.v. het TestCentre opgelost kunnen worden. Uitgebreidere test scenario’s t.b.v. Price en Packing dus.

Daarnaast is er in onze ogen een enorm potentieel aan interpretatie verschillen m.b.t. Price segmenten op diverse plekken.

Ik kan in theorie het volgende doen:
-          In het (hoofd) Price segment een bosprijs aangeven met een minimum van 1 bos en een maximum van 3 bossen.
-          Binnen het Packing segment kan ik een stuksopslag aangeven voor een minimum van 1 fust en maximum van 9 fusten.
-          Binnen het Delivery Segment kan ik voor de levering van morgen een bosopslag aangeven met een minimum van 1 bos en een maximum van 7 bossen.

Voor de levering van over twee dagen kan ik alle totaal andere combinaties aanmaken, ook i.c.m. verschillende afleverlocaties.

Ga dit maar eens importeren, opslaan in je database en vervolgens correct EN snel tonen in een webshop… voor 8000 artikelen (een potjes-en-pannetjes-leverancier i.c.m. twee grote bloemen leveranciers geven dit soort aantallen al).
Er zal dus een soort beperking in theoretische mogelijkheden moeten komen.

Bijvoorbeeld:
-          In elk Price segment dezelfde unitCode gebruiken voor de verschillende basisQuantity velden.
-          Alleen de combinaties van minimumQuantity en maximumQuantity die in het hoofd Price segment worden gebruikt, mogen ook in de sub Price segmenten (Packing, Delivery) worden gebruikt

Deze laatste twee stappen beperken de theoretische invulling al enorm.

Wellicht zijn er meer te bedenken, of moet het anders, maar dat zou m.i. in een werkgroep, of op een andere manier binnen de nieuwe structuur moeten plaatsvinden.

Ingediend door persoon Alexander v.Delft
Ingediend door community AlfaPro
Uitvoerder Leo Zandvliet
Status Gepubliceerd
Release ---
Prioriteit
Berichttype ---
Oplossing

16-08-2016: 
De volgende twee spelregels toevoegen aan de documentatie:

  • In elk Price segment dezelfde unitCode gebruiken voor de verschillende basisQuantity velden.
  • Alleen de combinaties van minimumQuantity en maximumQuantity die in het hoofd Price segment worden gebruikt, mogen ook in de sub Price segmenten (Packing, Delivery) worden gebruikt.

 

22-08-2016

Voorbeeld

 

Stel verpakkingsboom:

  • kar
  • 18 fusten
  • 5 bossen per fust
  • 10 takken per bos

En de kweker vult in z’n pakket in:
Prijs tot 100 stelen is €0,20 de steel
Prijs tot 2 - 9 fusten is €0,19 de steel
Prijs vanaf 1 kar is €162,- per kar.

Dan zullen in het bericht de volgende staffels verschijnen:
0-100 stelen => € 0,20
200-450 stelen => € 0,19
900 stelen => € 0,18

Bestelt iemand 800 stelen, dan krijgt die volgens de verpakkingsboom gewoon 16 volle fusten op een kar.
Er zijn in dit voorbeeld geen andere verpakkingsopties.
Als er wel andere verpakkingsopties zijn, dan moet een specifieke optie gekozen worden en kan de kweker software m.b.v. de optie bepalen om hoeveel fusten e.d. het gaat.

Optie

Wellicht zelfs middels een spelregel afdwingen dat altijd alleen de verkoopeenheid van het product uit het Linnaeus model aangehouden mag worden. Dit is dan bijna altijd 'per stuk/steel' en soms 'per bos'.
Problemen met prijs afrondingen moet de kweker software dan zelf per staffel oplossen, dit zorgt wel voor eenduidige berichten.

 

24-10-2016

Zomaar restricties of afhankelijkheden m.b.t. de eenheden doorvoeren is ondoenlijk zonder:

  • prijsstellingen uit de praktijk weer te kunnen geven
  • 'meer' problemen te veroorzaken

Uiteindelijk is de volgende spelregel wel doorgevoerd, waarmee hopelijk de huidige praktijk het best wordt omschreven en er ietsjes aan vrijheid wordt ingeboet:

The product price is expressed per stem, or if the marketplace allowes it, per bunch. The unit must be specified in each available packing option, as such the total number of stems can be calculated.

The unit used in the following elements, must be present in each packing option:

  • Quantity
  • IncrementalOrderableQuantity
  • Price/MinimumQuantity
  • Price/MaximumQuantity
  • DeliveryPrice/BasisQuantity
  • DeliveryPrice/MinimumQuantity
  • DeliveryPrice/MaximumQuantity

The unit used for the packing price, only have to present in the given packing price:

  • PackingPrice/BasisQuantity
  • PackingPrice/MinimumQuantity
  • PackingPrice/MaximumQuantity

With above rules, it must be possible to calculate the total number of stems in any situation.

The minimum and maximum quantities in each graduated price share the same unit per price type. 

Impactanalyse

16-08-2016: Als de aangedragen oplossing wordt uitgevoerd, zal dit een impact hebben op alle implementaties waar nu 'creatief' wordt omgesprongen met de prijsopbouw. Aanbod wordt niet meer ingelezen.

22-08-2016:
Kweker software zal verschillende invoer om moeten rekenen naar één eenheid alvorens het bericht op te stellen.
Koper software zal verschillende keuze mogelijkheden/invoer weer om moeten rekenen naar de eenheid welke in het bericht staat.

Opmerkingen CMG
Opmerkingen Kwaliteitsmanager
Aangemaakt door Marjo van der Sman
Aangemaakt op 17-9-2015 13:37
Gewijzigd door Marjo van der Sman
Gewijzigd op 23-10-2018 15:37