Heart-Profit ERP
September 21, 2024, 01:04:39 am *
Welcome, Guest. Please login or register.

Login with username, password and session length
News:
 
  Home Help Login Register  
  Show Posts
Pages: 1 ... 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 [171] 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 ... 273
2551  Heart-Profit Boards / Heart-Profit ERP Support / Re: Record not available op herhaling on: January 02, 2008, 11:16:13 am
Weet je zeker dat je mij hierover niet aan de lijn had (twee weken geleden) ?
Zo ik dat niet was, was er wel iemand anders met hetzelfde, en vind ik het geen toeval.


Trouwens, volgens mij is je verwarming lek.
2552  Heart-Profit Boards / Heart-Profit ERP Support / Re: Factureren maandklanten per 31-12-2007 on: January 02, 2008, 11:10:56 am
Het lijkt me dat wat Demis vertelt in de eerste post niet juist is. En als dat toch juist is, is het advies van Wouter niet goed.
Hoe dan ook, mijn idee hierover :

Een maandfaktuur doet het pas voor de afgelopen maand als je minimaal 1 dag verder bent dan die maand, en :
Vervolgens moet je de Faktuurdatum kunnen zetten op de dag die je wilt.

Dus Demis, jij geeft geloof ik drie redenen tegelijk aan waardoor het niet zou werken, en dat is "onzin";
Dat het programma de Faktuurdatum hanteert ter bepaling of de maandfaktuur de deur uit mag zou kunnen (en is dan fout), maar dat zou inhouden dat je halfweg de maand die faktuur er al uit zou kunnen krijgen middels het invullen van een faktuurdatum die de volgende maand impliceert. En dat is dan óók fout (twee keer).
Dat geloof ik allemaal niet.
2553  Heart-Profit Boards / Heart-Profit ERP Support / Re: hergebruik verpakkingen on: January 02, 2008, 11:00:10 am
Quote
Dit daar we in voorgaande jaren altijd anders een te hoge waarde op emballage kregen als de IBC's weer leek kwamen en de kaart "emballage in gebruik" liep dan altijd negatief. (boekten meer terug dan er opm stond)

Nu echter loopt de kaart de andere kant op.

Ik zou denken dat het tegenovergestelde aan de hand is t.o.v. wat Wouter al suggerereerde :
Je hebt ergens een proces (zoals Produktie) wat IBC's leeghaalt, en waar dit voorheen werd gejouraliseerd, gebeurt dit nu niet meer. Of beter : waar dit proces voorheen onder de kontrole van Profit was, is dit nu niet meer zo. Stom voorbeeld hiervan : voorheen gebruikte je een Produktieorder om de grondstof (uit IBC) af te boeken, en als de IBC leegraakte is kwam deze weer op voorraad en werd tevens als zodanig gejournaliseerd. Nu echter gebruik je hiervoor geen Produktieorder meer, maar je boekt handmatig de voorraad af ... en vergeet de lege IBC op te boeken.

Is maar een voorbeeld, maar in zo'n richting moet je denken.
Mag allemaal ook andersom hoor, waarbij mijn (dan andere) voorbeeld eindigt in " ... maar je boekt handmatig de voorraad op ... en vergeet de gebruikte IBC af te boeken.

Houd ook nog in de gaten dat het niet is gezegd dat je bij handmatige voorraadmutaties - van in dit geval Emballage - je automatisch de juiste waarde boekt. Dus, het handmatig op voorraad boeken van zo'n IBC ... wat voor'n financiële waarde kreëert dat bij jou ?
Ofwel, dit is niet gelijk aan Statiegeld, en als het wel zo is is het ook niet juist (zo'n ding kost nu eenmaal meer dan het statiegeld).

Let wel, ik blabla maar een beetje, en niemand hoeft mij denk ik te verbeteren; het gaat erom dat je doorgrondt welke processen wat doen, en dat je de processen (procedures) hoogstwaarschijnlijk ergens hebt verandert, maar je je misschien nooit hebt verdiept in de financiële konsekwenties.
Om een voorzetje te geven in jouw richting - wat misschien niet makkelijk is (en het voorbeeld misschien ook niet helemaal huist is) : je koopt nieuwe IBC's in die dus kwa waarde normaal op voorraad moet komen. Vervolgens moet je hierop toch ergens gaan afschrijven. Hoe ? geen idee, want jouw nieuwe IBC is binnen de kortste keren de deur uit en ... komt wel of niet weer terug, maar niet zo vaak.
Meteen in de kosten boeken kan ook, maar nu wel even aangeven wat je doet als 'ie weer terugkomt. Gratis ? Oorspronkelijke waarde ? idem minus afschrijving ? Statiegeld waarde ? Zie het maar consistent te krijgen met de eerste Goederen Ontvangst !

Ik denk dat je wel 100 dingen verkeerd kunt doen in jouw geval.
2554  Heart-Profit Boards / Heart-Profit ERP Support / Welk Emballage Saldo wil je eigenlijk handhaven ? on: January 02, 2008, 10:43:39 am
Dit is, zeg maar, ter info en het is misschien wel aardig als mensen hierop reageren en aan bijdragen :


Stel, Uw klant heeft een openstaand Emballagesaldo van 20 pallets. Bij een nieuwe order komen hier nog 5 pallets bij. De order wordt bij de klant geleverd, en de Pakbon zal de levering van 5 pallets verantwoorden. De Vrachtbrief is in staat om het openstaande saldo van in totaal 25 pallets te verantwoorden.

Echter... als op het moment dat de chauffeur bij de klant aankomt, uw expeditie-afdeling bezig is een nieuwe zending van 10 pallets voor te bereiden voor deze klant, dan is op dat moment zijn nieuwe saldo al 35. Dus, ondanks dat de 10 pallets nog niet de deur uit zijn, zal de opname van de 10 pallets al wel direkt het Emballagesaldo van de Debiteur bijwerken.

 
Op zich hoeft hier niets mis mee te zijn, immers, stel dat Uw klant er nu alvast 35 retour stuurt, dan kan hij bij de levering van de 10 pallets niets meer retour sturen.

In theorie kan echter de situatie ontstaan dat nog voor verzending de goederen niet een Europallet, maar op een Blokpallet de deur uit gaan, in welk geval de gekoppelde hoeveelheid europallets niet meer ontkoppeld kan worden omdat ze al retour zijn ontvangen.

Deze problematiek zou deels kunnen worden opgelost door te stellen dat bijv. extra meegeleverde Emballage welke aan een Raaplijst gekoppeld is, alleen mag meetellen voor het Emballagesaldo indien die Raaplijst is afgesloten (lees: de Pakbon gereed is). Op die manier telt de zending die voorbereid wordt pas mee in het Emballagesaldo op het moment dat de zending ook daadwerkelijk 'gereed' is, en klaar is voor verzending. 

Dit komt uit de Releasenotes en raakt de problematiek van de wens tot het in huis hebben van zo min mogelijk Emballage;
De programmatuur die rond deze tijd beschikbaar komt gaat hier expliciet op in, maakt gebruik van prints voor het uitstaande Emballage Saldo, scannen aan de deur om de uitstaande hoeveelheid te kontroleren, al dan niet mee terug te nemen en te boeken, en verantwoordingsoverzichten voor de klant zelf en desgewenst een email voor de klant op het Afleveradres die de verantwoording geeft van de zojuist meegegeven Emballage.
Denk hierbij aan algemene Emballage die als een pool door Nederland (of verder) zwerft, en houd hierbij in gedachten dat er vooral een surplus aan Embellage moet zijn, omdat anders niemand (zelf) zou kunnen leveren.


Met name denkend aan het laatste, zie je dat je van enig type nooit een Emballage Saldo van 0 wilt hebben. Immers, heb je 0 poolbakken, dan kun je zelf niet in poolbakken leveren. Dit zorgt er dus voor dat je *zelf* de wens hebt om een saldo groter dan 0 te handhaven.

Een klant die op enig moment 100 poolbakken van jou in huis heeft, heeft het recht om deze 100 naar jou terug te sturen. Let wel, dit is geen wet en bij een systeem zoals dat van poolbakken zou deze klant er ook 250 kunnen "terug"sturen. Dit mag zo werken omdat die 250 -waar je weliswaar statiegeld voor "terug"geeft- ooit weer door jou zelf ergens in rekening kan worden gebracht. Financieel komt het uiteindelijk dus wel goed, maar waar laat je die extra 150.
Dat je die 150 kwa statiegeld toch ook moet financieren is een afgeleide van alles en heeft er dus toch ook wel mee te maken.

Als je jezelf openstelt voor het ontvangen van Emballage zoals hier bedoeld, zit je binnen de kortste keren met magazijnen vol Emballage. Dit komt omdat iedereen er vanaf wil. Dit is op zich dan weer het gevolg van het gegeven dat er een surplus moet zijn (zie eerder), maar hoe groot dit surplus dan wel precies moet zijn is niet bepaald. Verder kun je zeggen dat het surplus altijd te hoog is, domweg omdat er niet tekort kàn zijn (als jij moet leveren, maar je hebt de Emballage niet, dan laat koop je het desnoods in bij een producent ervan). Daarnaast is het surplus te hoog omdat de buffers die overal optreden niet een vaste hoeveelheid betreft. Immers, als het met Kerst drukker is zul je meert Emballage nodig hebben - zal iederéén aan de leverende zijde meer Emballage nodig hebben, en de maand erop willen alle klanten die echt wel weer kwijt.
Met dit als voorbeeld zie je dat heel Nederland (etc.) eigenlijk het hele jaar door met te veel Emballage zit die eigenlijk nergens anders heen kan dan ... weer naar jou.
Nog maar eens gezegd : stel je je hiervoor open doordat je het niet geregeld hebt, en dan vooral in kombinatie met anderen die het wel geregeld hebben ("u heeft nooit zo veel van mij ontvangen !") dan stuurt iedereen alles naar jou.


Uit alles volgt dat de klant die met Kerst 100 poolbakken heeft gekregen, er recht op heeft deze ook terug te sturen. Dit is met goed fatsoen niet tegen te houden. Dus, ook al zou je het Saldo op 0 willen houden, het wordt vanzelf 100 minus de normale hoeveelheid buiten Kerst (stel 15) = 85 keer het aantal klanten.
Verder, stuur je inderdaad aan op een Saldo van 0, dan hèb je ook 0 indien je er intussen voor hebt kunnen zorgen die 85 (keer het aantal klanten) gedurende het jaar kwijt te raken. En dus heb je tegen de tijd dat het 0 is geworden ook werkelijk tekort. Met Kerst zelfs 100 keer het aantal klanten.

De funktionaliteiten zoals Profit die binnenkort biedt doen niet meer dan inzicht geven in het momentele Saldo, waarbij je zelf in de hand hebt (en moet houden) tot hoever je het Saldo wilt laten dalen op enig moment.
Enige intelligentie in het vastleggen hoe je de Saldi per seizoen e.d. wilt hebben is niet aanwezig, maar zou theoretisch gezien kunnen worden ontwikkeld.

Houd in het achterhoofd dat als alle leveranciers dit goed hebben geregeld, Nederland vast loopt met de Emballage, omdat in dat geval in eerste aanleg de klanten ermee zullen blijven zitten, deze het recht hebben om het terug te sturen, en omdat er nergens een (leverancier) gek meer is te vinden die zijn magazijnen beschikbaar stelt, zal iedere leverancier toch zijn aandeel weer moeten nemen. Wiskundig gezien komt dit weer neer op de 85 keer het aantal leveranciers uit het eerdere voorbeeld.

Aldus moet het duidelijk zijn dat de geboden funktionaliteiten niets anders kunnen doen dan het ervoor zorgen dat je niet nog meer krijgt dan genoemde 85. En, zolang er gekken zijn die het niet hebben geregeld, zullen die meer hebben, en jij minder dan de 85.


De pools die bij vervoerders huizen betreft een fenomeen waarvan wij op dit moment niet kunnen doorgronden hoe dit in het geheel past. Denkelijk kan het door de klant in deze worden gezien als "een leverancier", waarbij meerdere werkelijke leveranciers die van dezelfde vervoerder gebruik maken voor die klant de efficiency in zich heeft dat de klant dit als één kan zien, waar het er anders meerderen zouden zijn. De kans lijkt echter gering dat deze efficiency (vaak) optreedt.
Wel is de vervoerder in zo'n geval een extra buffer (met magazijnen ?), die aldus bijdraagt aan de mogelijkheid van het surplus zonder dat de klant of jij ermee zit.

Peter
2555  Heart-Profit Boards / Chat / Prettige feestdagen iedereen ! on: December 24, 2007, 10:14:15 am
Nu was onderstaand plaatje wel van zaterdagmorgen en is alles intussen weer gewoon groen, maar je weet maar nooit ...

Wit of groen, iedereen een gezellige tijd toegewenst, met dank voor de samenwerking het afgelopen jaar. yes
Peter
2556  Heart-Profit Boards / Chat / Re: Beveiliging usb-randapparatuur on: December 24, 2007, 10:09:32 am
Tja ... zoiets is wel een goed idee.
Ik kan zo snel niet zien waar Profit last van zou moeten hebben, mits je maar voldoende gedetailleerd kan afschermen (dus bijv. alleen dat sticky of desnoods de USB poorten, in plaats van het hele netwerk smile).

Of je dan verder nog wel je digitale camera kunt gebruiken ... dat zal van zo'n tooltje afhangen.

Ben zelf wel benieuwd naar de ervaringen (tegen de tijd dat die er zijn), want eiiiigenlijk is het wel redelijk onontbeerlijk ...
2557  Heart-Profit Boards / Heart-Profit ERP Support / Re: Kan emballage niet verwijderen on: December 24, 2007, 09:12:57 am
Kan het kwaad als dit even zo blijft staan ?
Alle geleerden die weten hoe het bij jullie in elkaar zit zijn er niet ... Cry
2558  Heart-Profit Boards / Heart-Profit ERP Support / Re: Extra kolom bij raadplegen geleverde charges on: December 21, 2007, 01:15:12 pm
Geen idee. Als jij met een resolutie van 640x480 werkt zal dat toch z'n invloed zo wel hebben ...
smile
2559  Heart-Profit Boards / Heart-Profit ERP Support / Re: VERKOOPOVERZICHTEN Gerealiseerd 8.3.2.2 Leverancier on: December 21, 2007, 01:14:27 pm
Quote
Ps jouw overzicht is gefactureerd en het moet echt bij gerealiseerd.

Sorry. Ik geef voortaan wel geen voorbeelden meer. Geeft dat ook geen misverstanden ...
Pffff
2560  Heart-Profit Boards / Heart-Profit ERP Support / Re: VERKOOPOVERZICHTEN Gerealiseerd 8.3.2.2 Leverancier on: December 21, 2007, 11:30:55 am
Het kan ook voor 2,5 uur smile :

Zie onderstaand voorbeeld, waarbij je "Huidige Verkoper" moet vervangen door "Voorkeur Leverancier", en Ja (niet default) aangeeft dat je het overzicht op basis van de Voorkeur Leverancier wilt hebben.

Merk op dat je dan niet kunt kombineren met Werkelijke Leverancier, waarvan ik zelf het nut niet kan (in)zien, maar jij misschien wel.
2561  Heart-Profit Boards / Heart-Profit ERP Support / Re: Extra kolom bij raadplegen geleverde charges on: December 21, 2007, 11:00:35 am
Voor wat betreft de eerste 20 posities ... vind je dat goed ?

N.b.: Als het projekt klaar is van a. het weergeven van de volledige inhoud van een kolom, maar b. het door de gebruiker kunnen vastzetten van de (breedte van de) kolommen, kun je zelf bepalen hoeveel je ervan ziet (ten koste van de rest).
Hier weet je zelf alles (nou ja, veel) van ... yes

1,25 uur.

Heart Intern : Géén rekening houden met Dos ! (dus daar dondert de boel rechts van het scherm af).
2562  Heart-Profit Boards / Heart-Profit ERP Support / Re: VERKOOPOVERZICHTEN Gerealiseerd 8.3.2.2 Leverancier on: December 21, 2007, 10:49:33 am
Nu ga je een heel raar antwoord krijgen :

De werkelijke Leverancier veranderen in de Voorkeur Leverancier vinden wij zonde van de gedane moeite en omdat dat het de werkelijke Leverancier mooi is voor het pakket.

De Voorkeur Leverancier erbij kost 4 uur.


Tja, wat moet je met die gasten uit Barneveld ...
2563  Heart-Profit Boards / Heart-Profit Releasenotes / Re: Available To Promise (ATP) check bij Verkooporderregels (2) on: December 21, 2007, 09:13:20 am
Voor diegenen die zich afvragen wat nu al de ophef is over een Available To Promise Check, het betreft hier een volledige multi level ATP check, en dus niet alleen voor het verkochte produkt en het niveau van de grondstoffen/halffrabrikaten daar direkt onder. Het betreft dus *alles*.

Wij hebben zelf gesteld dat het werken met de ATP check - welke dus tevens ervoor zorgt dat produkties e.d. worden ingeplanned - eigenlijk gepaard dient te gaan met een gedegen grafische planning. Deze zal dan ook in de komende maanden beschikbaar komen in een eerste versie.
2564  Heart-Profit Boards / Heart-Profit ERP Support / Re: DKK bij pickorder on: December 19, 2007, 04:00:37 pm
En Thomas, wat je wilt kan sowieso; zijn expliciet voorzieningen voor in het systeem opgenomen (m.n. speciale journaliseringen bij G.O. van een Externe Verplaatsopdracht (Pickorder)).
2565  Heart-Profit Boards / Heart-Profit ERP Support / Re: LOLAPRWY ook voor prijsafspraak leverancier (LOPL) on: December 19, 2007, 10:46:23 am
Je zou kunnen beginnen met gewoon een vraag te stellen. Tot nu toe zie ik die niet in dit topic.
Pages: 1 ... 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 [171] 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 ... 273
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.765 seconds with 12 queries.