Heart-Profit ERP
October 02, 2024, 12:29:59 am *
Welcome, Guest. Please login or register.

Login with username, password and session length
News:
 
   Home   Help Login Register  
Pages: [1]
  Print  
Author Topic: Registratie Ontvangstlokatie bij Afleveradres  (Read 1182 times)
0 Members and 0 Guests are viewing this topic.
Heart Informatisering B.V.
Partner
******
Offline Offline

Posts: 27469


View Profile WWW
« on: June 04, 2018, 10:44:17 am »

Als we een Inkooporder plaatsen bij een Leverancier, bevat de I.O. (onder in het scherm) de gegevens waar de goederen moeten worden Afgeleverd. Omdat u meerdere Afleverlokaties kunt hebben (bijv. één voor ieder Magazijn) én het zonde is om een separate Toevoegen-/ Wijzigen-/Verwijderen-/Raadplegen Afleveradressen Inkooporders te ontwikkelen, maakt de Inkooporder gebruik van een Afleveradresvolgnummer zoals deze bij de Debiteuren gegevens wordt gebruikt. De Inkooporder vraagt nu simpelweg om een Afleveradresvolgnummer, en de NAW gegevens van dat volgnummer (met als Debiteuren-Id "het aktieve bedrijf") bepaalt welk Afleveradres er naar de Inkooporder wordt gekopieerd. So far so good.

Als we met de module Profit-Intercompany werken is van oudsher vaak een parameter aktief die Relatie-gegevens Intercompany kopieert naar alle bedrijven. Sinds enkele jaren hoeft deze parameter niet meer aktief te zijn, en geldt dat we Intercompany uitbestedingen niet meer doen aan de Debiteuren-Id in 'het andere bedrijf', maar we kopiëren slechts de Afleveradresgegevens door naar een algemeen 9999 adres. Het voordeel hiervan is dat u niet meer hoeft te beschikken over alle Debiteuren en Afleveradressen van uw Intercompany bedrijven, en tóch aan alle Debiteuren van uw Intercompany bedrijf kunt leveren.

Als we deze Relatie-gegevens niet Intercompany kopiëren, dan geldt het advies om dit v.w.b. diverse Intercompany zaken wél te doen. Bedenk dat als u een Artikel "A" maakt, en dat Artikelnummer niet gereserveerd wordt in een ander bedrijf, het andere bedrijf vroeg of laat ook een Artikel "A" kan verzinnen, en daar misschien totaal iets anders mee bedoelt. Op zo'n zelfde manier gaat dit op voor Afleveradressen.

In een live voorbeeld is nu gekonstateerd dat een fysiek Magazijn in Bedrijf A (die inkoopt bij B) een Afleveradresnummer #66 vertegen woordigt. In bedrijf B is ditzelfde Magazijn opgenomen als Afleveradres #76. Normaal gesproken geldt dat als A inkoopt bij B, en we in A een Afleveradres #66 selekteren, ook B zal moeten leveren op Afleveradres #66. Tsja... dat is nu niet dezelfde, omdat er geen Relatiegegevens Intercompany worden gekopieerd (en de klant dit zelf niet consistent houdt).

Er blijkt funktionaliteit te zijn, initieel ontwikkeld t.b.v. Externe Verplaatsopdrachten, die er voor zorgt dat dit funktioneel toch kan werken, maar, aanvullend hierop hebben we m.i.v. deze Releasenote daar wat aanpassingen en kontroles aan toe moeten voegen.

Bij de Afleveradressen van een Intercompany Debiteuren hebben we nu een 3 tal Lokaties. Twee daarvan hadden we al, en een derde is toegevoegd.

1. Raapvloer
* Hiermee geven we aan dat als we een Verkooporder hebben aan een bepaalde klant, de order vanaf deze Lokatie moeten leveren. Deze rubriek is bedoeld om bijv. in te kunnen richten dat als wij een Verkooporder aan een Nederlandse Debiteur hebben, dit vanuit ons eindproduktenmagazijn geleverd moet worden, maar als we een verkooporder aan een hongaarse klant hebben, de order moet worden geraapt vanuit het Externe Magazijn in Hongarije.

2. Intercompany Ontvangstlokatie
 * Deze werd gebruikt om bij een Intercompany order het Afleveradres in het Leverende bedrijf te bepalen, op basis van een Ontvangstlokatie in het Ontvangende IC bedrijf. Dus, stel dat ons IC bedrijf iets inkoopt en Afleveradres #66 selekteert, dan kan ze bij de Inkooporder aangeven dat deze inkoop t.b.v. Ontvangstlokatie "AB" is. Als in bedrijf A een Inkooporder wordt gegenereerd bij bedrijf B, dan zal B een Verkooporder hebben aan A. Het Afleveradres volgnummer welke nu in bedrijf A aan de Verkooporder wordt gekoppeld is in eerste instantie gelijk aan de bij de Inkooporder ingevulde #66, maar, wordt daarna direkt overruled met het Afleveradres die als "Intercompany Ontvangstlokatie" de waarde "AB" ingevuld heeft. Dus, als Afleveradres #76 verwijst naar IC Ontvangstlokatie "AB", dan zal de Verkooporder in B een Afleveradres #76 toegekend krijgen. De Afleveradres volgnummers hoeven nu in A en B niet meer synchroon te lopen.

Het probleem wat nu ontstaat is dat als we in bedrijf A gaan inkopen, we een Afleveradres #66 invullen en daarmee een bepaald Magazijn (AB) mee bedoelen. De bepalen van het Afleveradres in het leverende bedrijf (B) werkt op zich prima op basis van de in bedrijf A ingevulde Ontvangstlokatie, maar... niets dwingt af dat in bedrijf A Afleveradres #66 wordt geselekteerd, er ook verplicht AB moet worden gehanteerd als Ontvangstlokatie, die we immers nodig hebben om nu bedrijf B het juiste Afleveradres te kunnen laten bepalen. Derhalve is er m.i.v. heden nog een 3e Lokatie opgenomen bij het Afleveradres van een Debiteur, en dat is de Ontvangstlokatie t.b.v. een Inkooporder.

In Bedrijf A kopen we iets in bij bedrijf B. Bij Afleveradres #66 kunnen we nu aangeven dat als we dit Afleveradres gebruiken in een Inkooporder, dit een Ontvangstlokatie "AB" moet triggeren. En omdat in bedrijf B er een Afleveradres #76 bestaat waar weer "AB" staat ingevuld als IC Ontvangstlokatie, kan zodoende de link worden gelegd met het leverende bedrijf.

FunktieOmschrijvingDtm.Vl.WyzDtm.L.Wyz
LOICAAWY    Omschrijving (nog) niet bekend    11-11-2005    04-06-2018
LOIOTV      Toevoegen Inkooporders    30-12-2016    31-05-2018
LOIOWY      Wijzigen gegevens Inkooporder    31-05-2018    04-06-2018
LORDAARA    Raadplegen Afleveradr. Debit.    31-05-2018    31-05-2018
LORDAATV    Toevoegen Afleveradressen Deb.    24-05-2018    31-05-2018
LORDAAVA    Omschrijving (nog) niet bekend    24-02-2014    31-05-2018
LORDAAWY    Wijzigen Afleveradressen Deb.    20-09-2016    31-05-2018
Logged
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1 RC2 | SMF © 2001-2005, Lewis Media Valid XHTML 1.0! Valid CSS!
Page created in 0.156 seconds with 20 queries.