Met dank Wouter, het was inderdaad een beschadiging in LODF
de hergegenereerde factuur na reorg van LODF ging wel goed

MK

-----------------------
OK doe ik vanavond

Persoonlijk vond ik mezelf al slim dat ik de referentie naar het regelnummer had verzonnen. Maar jij denk duidelijk veel verder door 

Ja hoor, ik heb hem apart gehouden.
Had het alleen nog niet zelf gedaan zodat je de boel nog kan zien /  naspelenmvg

MK

Kan hier op termijn bij de foutmelding ook het regelnummer van de afgeroepen journaalpostdefinitie worden getoond.

Dus bv de melding : "Credit rekening mag geen balans rekening zijn"
aanpassen naar "Regel B : Credit rekening mag geen balans rekening zijn"


Dat zou het "debuggen" van foutmeldingen een stuk versnellen


mvg

Marco

Ik heb order 20080304006
Hierop stata een DKK voor de verpakkingsbelasting

Deze regels is gesplitst naar 3 leveringen welke elk apart geleverd zijn
basis order was de 20080226014


Factuur 2043605 gaat zonder DKK !!                           order 20080304006
Factuur 2043606 gaat met DKK tegen correct tarief       order 20080304007
Factuur 2043607 gaat met DKK tegen correct tarief       order 20080226014


Gaarne even nakijken waar dit fout loopt?
Volgens mijn afdeling verkoop komt de DKK wel op de orderbevestiging
en staat hij ook op de order, maar niet op de factuur

Hij blijft dus ergens "hangen"

Asl onze mensen erg snel tikken dan treedt het regelmatig op dat de desbetreffende persoon meldingen krijgt als:

KONVERSIE VAN E62 NAAR KG NIET MOGELIJK


Het lijkt erop dat als je sneller gaat dan Profit op dat moment wil, het mogelijk is om het linker deel van de locatie in het eenheidveld te krijgen.

Dit heb ik al van meerdere personen te horen gekregen.
wat in de praktijk gedaan wordt is het volgende:

5.2.2.1   of userbutton naar LOPOAB
en PO nummer met F1
dan op betreffende grondstofregel gaan staan
Middels F4 afboekscherm openen
Middels F5 voorraad raden
op gewenste regel gaan staan F1 lezen
dan 2*esc en gewenste artikel afboeken

De zeer snelle tikkers krijgen de bovengenoemde fout regelmatig (volgens zeggen)

is wat mij betreft accoord
dus UF-FADOBNUM wordt gevuld met de relatie-BTW welke overschreven wordt door een aanvullend BTW nummer per afleverland mits deze in de subtabel is kenbaar gemaakt.

Wij werken met "verzamelfactuur layout" waar afleveradres gegevens op regelniveau worden weergegeven

UF-FADOBNUM staat bij ons in de header maar geeft het BTW nummer van de relatie-Id

Sommige grotere organisaties hebben echter een BTW nummer per land.
Dus als ik een order van een multinational krijg heb ik per afleverland een BTW nummer
In dit geval 213261 is gekoppeld als relatie in Zwitserland met een CH BTW nummer
Echter voor NL hebben zij ook een NL nummer.

De factuur gaat in dat geval goed (van nederland NL naar afleverades NL) met BTW
Maar zij willen dan ook hun NL BTW nummer zien op de factuur.
En van andere landen als dat van toepassing is.

Kan iemand mij zeggen welke variabele dit is, c.q. wat het kost om deze op HH niveau beschikbaar te maken (bron : raden relaties op Id - Shift F7 Iso landen BTW koppeling)

mvg

Marco

Peter,

Als je meer info krijgt houden wij ons aanbevolen om hier eens mee te spelen/naar te kijken/ mee te denken

MK

domme vraag, maar waarom volg jij jouw leverancier 1:1?
waarom aan jouw kant niet inrichten als artikel/verschijning en dan bij leverancier op artikel/verschijning zijn "unieke" artikelnummer eraan hangen?

zo werken wij tenminste zowel aan inkoop als verkoopzijde
(en SAP ken ik wat dat betreft goed)
Dus leverancierskode bij artikel F2 H opgeven en onder 3.5 klantgerichte gegevens het debiteuren artikelnummer.

binnen ieder artikel blijft de fifo gewoon werken zoals het al deed, immers als je het oplost zoals wij het doen praat je over achtervoegsels.

Bij ons speelt dit trouwens niet daar wij op FIFO THT werken. Wij gaan ervanuit dat je minimaal 2 leveranciers probeert te hebben voor elk artikel en dan gaat FIFO op charge sowieso altijd fout

Nee, dat is dus niet waar, immers ik koppel nu op basis van de leverancier en niet op basis van de goederenstroom. Dus mijn koppeling is niet sluitend.

Maar wat ik wel aangeef is dat ik met spanning wacht op jouw voorzet voor een module die dit regelt. Middels welke je opslagen op de kostprijs kunt maken en misschien ook wel de aangifte per samenstellende component kunt doen?

Kijk, want daar wil ik in de toekomst waarschijnlijk wel naartoe. 

Maar ook ik snap dat je dat niet in 4 dagen opgetuigt krijgt dus blijf ik in "blijde verwachting"

En dat heeft helemaal niets met die 47 uur te maken.

Dus die Good Job mag je bij jezelf zetten.. 

De enige andere echte oplossing is het herstructureren van Heart en zoals Wouter al aangaf alles op crediteur/artikel/charge gaan omzetten

Als je dat wilt betekent dat even de hele module inkoop en management overzichten omzetten + nog alle zaken die hiernaar verwijzen.

Ik weet wel dat ik dat niet ga betalen op basis van het uurtarief...
Dus was de melding de enige economische oplossing voor mij als "domme" gebruiker.
Let wel dit neemt niet weg dat het een lapmiddel is van een onvolkomendheid in het datamodel vs. de realiteit.

Deze discussie heb ikm al uitgebreid gevoerd met Menno
(zie oude posts)

Het probleem is dat Heart ervanuit gaat dat de leverancier ook een producent is met een eigen batchnummer systeem.

Het feit is echter dat leveranciers vaak handelaren zijn en het dus zeer wel denkbaar is dat een gelijke batch referentie op 2 producten hangt.

Probleem is dat de sleutelvelden mbt ontvangst goederen en batches raadplegen hier niet op zijn ingericht en daarom heeft Heart als "noodverband" er een controle ingebakken welke ervoor zorg draagt dat je geen 2 gelijke batchnummers op 1 leverancier kunt gebruiken voor 2 verschillende artikelen.
Anders kun je n.l. nooit de keuringen e.d. dara meer van invullen.

Dit is echt zo bij ons voorgekomen.

http://ha1.heartprofit.nl/profit/index.php?topic=18456.msg24774#msg24774