Heart-Profit ERP

Heart-Profit Boards => Heart-Profit Releasenotes => Topic started by: Heart Informatisering B.V. on June 19, 2015, 02:10:11 pm



Title: Blokkeren "DryDock" (Goederen komen Retour) (2)
Post by: Heart Informatisering B.V. on June 19, 2015, 02:10:11 pm
Een deel van Releasenote http://ha1.heartprofit.nl/profit/index.php?topic=26796.0 is per heden weer ongedaan gemaakt. Dit, omdat het feit dat de Verkooporderregel Credit helemaal niets Intercompany doet, in bepaalde gevallen toch wenselijk kan zijn.

Indien NL een order heeft voor een schip in NL, en 100 levert, dan moet ze 20 retour kunnen boeken, en dient er per saldo 80 aan de klant (het schip) te worden gefaktureerd.

Indien NL een order heeft voor een schip in IT, deze order uitbesteedt aan IT, en IT gaat 100 leveren op de order, maar wil er later 20 retour boeken, dan is het logisch dat de 20 in IT retour komen, dat IT er 80 aan NL faktureert, en dat NL 80 aan de klant faktureert. Helaas: dit deel werkt niet, omdat de VO regel Credit helemaal niets doet "in het andere bedrijf" (is nooit gemaakt).

Indien NL een order heeft voor een schip in TR, deze order uitbesteedt aan TR, en TR gaat 100 leveren op de order, dan moet TR deze voorraad eerst uitklaren. De voorraad wordt nu van NL, en als er dan iets 'retour' komt, dan wordt deze retour juist niet in TR geboekt (zou immers weer iets als inklaren vereisen). Als we nu deze retour in NL boeken, dan doet dit niets Intercompany, maar... dat komt in deze situatie nou net goed uit ! immers NL was eigenaar geworden van de voorraad.

Nb: Het feit dat de uitbesteding aan een bedrijf buiten de EG plaatsvindt en de goederen derhalve uitgeklaard moeten worden kon hier wel eens impliceren dat het juist wenselijk is om de retour niet in TR te boeken, maar in NL.

Resumer, in de vorige Releasenote is de DryDock retour o.a. geblokkeerd voor Intercompanyorder en Uitbesteedde orders. Die laatste kategorie wordt per heden weer toegestaan.

Let op: bij de klant voor wie e.e.a. ontwikkeld is, en voor wie e.e.a. is dichtgespijkerd, zorgt er zelf voor dat er geen DryDock retouren worden geboekt op orders in IT, waardoor de genoemde (niet werkende) situatie niet optreedt (maar dus nog wel fout gaat als het wel zou worden gebruikt!)

FunktieOmschrijvingDtm.Vl.WyzDtm.L.Wyz
LOVOTV      Toevoegen Verkooporders    19-06-2015    19-06-2015
LOVOTVVA    Omschrijving (nog) niet bekend    19-06-2015    19-06-2015
LOVOWY      Wijzigen Verkooporder    18-06-2015    19-06-2015
LOVRTV      Toevoegen Verkooporderregels    18-06-2015    19-06-2015
LOVRTVEX    Toevoegen Verkooporder-regels. Uitbreiding    19-06-2015    19-06-2015
LOVRTVG2    Omschrijving (nog) niet bekend    18-06-2015    19-06-2015
LOVRTVGE    Omschrijving (nog) niet bekend    19-06-2015    19-06-2015
LOVRWY1     Omschrijving (nog) niet bekend    18-06-2015    19-06-2015


Title: Re: Blokkeren "DryDock" (Goederen komen Retour) (2)
Post by: Wouter Rijnbende on December 17, 2015, 10:33:16 am
De uitleg nog eens teruglezend, is toch niet duidelijk waarom deze blokkade ongedaan gemaakt is, met vervolgens 'fout lopen' als mogelijk resultaat.

Met een blokkade op 'DryDock Retour is niet toegestaan als de Debiteur een IC bedrijf is', zou NL nog steeds een retour van 20 moeten kunnen boeken. NL heeft nl. een order aan een klant (een schip) en niet aan een IC bedrijf. De order in Italie staat wel op de Debiteur IC bedrijf NL, en Italie zou dus geen DryDock retour mogen boeken. Staan we dit daar wel toe, dan faktureert Italie er 80 aan NL, maar NL faktureert er gewoon 100 aan haar klant (die de 20 netjes retour gezonden heeft).

Het beschreven voorbeeld voor Turkije is op zich niet veel anders.

Merk op dat als de klant er 20 retour stuurt, we dit altijd moeten kunnen boeken in het bedrijf die de order aan de klant heeft. In Turkije pakt dat dan toevallig goed uit, omdat Turkije uitgeklaarde goederen niet opnieuw gaat inklaren, en dit feitelijk een stukje voorraad van Nederland geworden is als dit retour gezonden wordt. Bij de uitbesteding aan Italie geldt op zich dat die voorraad wel degelijk in Italie retour zal komen, maar daar niet geboekt kan worden (omdat dit niet ontwikkeld is). De klant voor wie dit ontwikkeld is gebruikt dit ook niet in die situatie, en vandaar alsnog weer de twijfel, waarom is die kontrole er 2 dagen later weer uitgesloopt ? Nu lopen we er weer tegen aan.