Calculatie (nieuw)

[Een ex-gebruiker]

Incoterms

Incoterms zijn de basis van de calculatie. De incoterm bepaalt mede welke delen van de prijs berekend moeten worden. Op deze manier kunnen we makkelijker meer prijsvarianten bieden (evt. op aanvraag).

• LCL/FCL import
  De LCL termen zijn geen incoterms. Zijn deze termen te vertalen naar echte incoterms?

  • Haven tot Haven (FOB, zeevracht, POD-THC, inklaring)
  • Haven tot Deur (FOB+ ??, zeevracht, POD-THC, inklaring, transport)

• LCL/FCL export
  Deze termen zijn niet accuraat, Haven tot deur zou van Deur tot Haven moeten zijn.

  • Haven tot Haven (CIF?, Uitklaring, POL-THC, FOB, zeevracht)
  • Haven tot Deur (EXW ?, Transport, Uitklaring, POL-THC, FOB, zeevracht)

• Air import
  Deze prijsgroep werkt al met incoterms

  • FOB, zeevracht, POD-THC, inklaring
  • FCA, Uitklaren, POL-THC, zeevracht, POD-THC, inklaring
  • EXW, Lokaal transport, Uitklaren, POL-THC, zeevracht, POD-THC, inklaring

  Al deze incoterms zijn mogelijk met transport naar eindklant, wat weer buiten incoterms valt.

• Air export
  Deze prijsgroep werkt al met incoterms

  • FOB, Uitklaren, zeevracht, POD-THC
  • FCA, Uitklaren, POL-THC, zeevracht, POD-THC, inklaring
  • EXW, Lokaal transport, Uitklaren, POL-THC, zeevracht, POD-THC, inklaring

Aan incoterms kunnen wellicht verschillende types prijsfactoren verbonden zijn die daar verplicht bij horen, om trajecten waar die prijzen niet beschikbaar zijn te kunnen invalideren.
Ook incomplete trajecten moeten kunnen voor evt overwijzingen.
FAK/NAC verschil (guaranteed space) in incoterms uit laten komen.

Units

Per incoterm wordt voor alle units van de prijsgroep een prijs berekend.
LCL: cbm1, cbm2, cbm3, cbm4, cbm5, cbm6, cbm7, cbm8, cbm9, cbm10
FCL: ft20, ft40, ft40hc
Air: day1, day3-5

Bij Air gelden hierbij het aantal chargeable kilos als quantity. Voor FCL moet een aparte quantity komen om meerdere containers in één order te zetten.

Prijsfactoren

Aan prijsfactoren moet meer informatie gekoppeld worden voor beter prijsmanagement en om een betere verwerking te krijgen in orderbeheer.

• Begin- en einddatum voor tarief
• Munteenheid om Dollarprijzen in te kunnen voeren voor toepassing dagkoersen.
• Agent-Carrier voor boeking. Aan de "Oceanfreight" prijsfactor (speciale status) wordt een Agent-Carrier combi gekoppeld. Andere prijsfactoren worden aan deze agent gematched. Hierdoor kunnen meerdere prijssets voor meerdere agenten/carrier aan één haven gekoppeld kunnen worden, en de goedkoopste prijs berekend worden.
• Inkoopprijscalculatie gekoppeld aan leverancier tbv factuurcontrole
• Prijsfactor voor 'oceanfreight' moet aparte status hebben, voor validatie van prijzen en vergemakkelijking van import. Wellicht dat dit zinvol kan zijn voor meerdere types. komt op type-niveau, factor-surcharge-oceanfreight
• Prijsfactoren moeten nestable zijn voor volgordebepaling en sub-prijsfactoren.
• Wel/niet zichtbaar op factuur (bijv agent fees), maar wel berekend in de totaalprijs (wellicht koppelen als sub onder de prijsfactor waarvan de beschrijving wel getoond wordt)
• Om meer grip te krijgen op de verkoopprijzen, moet een prijsfactor zijn eigen marge kunnen hebben. Die marge kan komen vanuit een hoger level (pol, pod) of uit de prijsfactor zelf.
• De inkoopprijs moet onafhankelijk van de verkoopprijs aangepast kunnen worden om de uiteindelijk kostprijs calculatie te kunnen verfijnen naarmate er meer data beschikbaar is (exact CBM, evt GRI). Dit moet kunnen worden aangepast in de verzending en alleen optioneel doorberekend worden aan klant. Hiervoor moet de prijsfactor de berekende verkoopprijs in zijn eigen data opslaan.
• Prijsfactoren van type 'factor' (kortingen, dieseltoeslagen) moeten de optie hebben om voor òf na toepassing van de marge toegepast te worden.
• Mogelijkheden om extra condities aan prijsfactoren te hangen die afhankelijk zijn van de verzending-data/incoterm. Bijv. kosten gebruik export-vergunning, ex-works kosten, etc.

Praktische ondervindingen
Eerste ondervindingen bij maken code:

• Tariefdatum invoeren:
  • Lastig te zien hoeveel er nog in toekomst in staat.
  • Gevaar voor niet aansluitende prijzen-sets
  • Voorkomen "veranderen en verlengen", dus makkelijk nieuwe tariefdatum kunnen maken
  • Zo veel mogelijk het prijsfactor-beheer per import doen
  • Tarieven zonder einddatum toestaan
• Parent pricefactor is heel makkelijk om een tariefblok van 1 agent en datum met meerdere kostensoorten aan elkaar te verbinden.
  -Pricefactors zouden moeten bevriezen zodra ze geldig worden. Wijzigen is dan alleen mogelijk als nieuw tariefblok met datum vandaag.

Over na te denken

• Prijsfactor hoeft niet aan een agent gekoppeld te zijn (bijv bij bedrijf, of algemene kosten haven). Hoe om te gaan met ranges.

Er moet een state bijgehouden worden van actual params (cbm, kgs, km, etc) en de calculated params (die aan klant berekend/bekend zijn).
Het liefst ook mogelijkheid om historie van calculaties terug te zien. Hoe dat te doen zonder heel veel db-entries.

Beschrijving algoritme

Invoer via zoekopdracht
Invoer van tenminste zoekmodus (sea_import, sea_export, air_import, air_export) en POL. Eventueel aangevuld met POD en afleveradres.

• Uit alle schedules worden de geldigen (datum, zoekmodus (prijsgroep), POL) gezocht.
• Hier worden alle mogelijke prijsgroepen en PODs uit geëxtraheerd.
• Alle mogelijke transportprijzen/prijsfactoren die nodig zijn voor transport worden ingeladen in de TransportCalculatorInput.
• Alle prijsfactoren die nodig zijn worden ingeladen in de CalculatorInput.
• Alle prijsgroepen, POL-POD combi's en evt afleveradres worden in algemene calculatie berekend.

Invoer via geboekte verzending
Prijsgroep, POL, POD en eventueel afleveradres zijn gegeven.

• Alle prijsfactor-data wordt in CalculatorData object opgeslagen en ingeladen in CalculatorInput/TransportCalculatorInput. Alleen bij hercalculatie of bij gewijzigde pol-pod-afleveradres etc wordt deze data opnieuw uit de havens/shippers etc geladen.
• Prijsgroep, POL-POD en evt afleveradres wordt in algemene calculatie berekend.

Algemene calculatie
Berekening van alle incoterms/units van een POL-POD combinatie en evt. afleveradres voor alle transporteurs/agenten.

• Bereken eerst de transportprijzen van verschillende transporteurs vanaf POD-afleveradres.

• Hieruit wordt de goedkoopste gekozen.

• Verzamel alle prijsfactoren die van toepassing zijn op deze incoterm/unit/agent/quantity.

• Pas prijsfactoren type 'factor vóór marge' toe op deze factoren.

• Zoek bij de prijsfactoren de marge die daar op berekend zou moeten worden.

• Bereken de verkoopprijs per prijsfactor.

• Pas prijsfactoren type 'factor ná marge' toe op deze factoren.

• Tel de verkoopprijzen op om tot een totaalprijs te komen.

• Tel de transportprijs op als van toepassing.

• Bij LCL deel door aantal cbm.

• Rond de prijs af naar eerste hele euro.

• Vermenigvuldig met Quantity/CBM. Dit levert een afgeronde totaalprijs op, die hoger is dan de gecalculeerde prijs.

• Afrondingsverschil wordt als onzichtbare prijsfactor toegevoegd.

• Kies de goedkoopste agent.

Factuurspecificatie

Op de factuur worden de berekende verkoopprijzen terug gesplitst naar prijsfactoren en gespecificeerd. Prijsfactoren die niet op factuur vermeld moeten worden, moeten bij een "parent" prijsfactor opgeteld worden.

Calculatie Data

De input van de calculatie wordt opgeslagen in de DB calculatie_data.