Heart-Profit ERP
July 06, 2024, 10:41:41 am *
Welcome, Guest. Please login or register.

Login with username, password and session length
News:
 
  Home Help Login Register  
  Show Posts
Pages: 1 ... 138 139 140 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 ... 273
2506  Heart-Profit Boards / Chat / Grafische Planning on: January 23, 2008, 02:46:37 pm
Alhier enkele screenshorts van de op handen zijnde geïntegreerde grafische planning.
E.e.a. vooralsnog als anouncement dat we er mee bezig zijn, en om een korte indruk te geven.

De omschrijving "Grafische Planning" is met opzet niet produktie georiënteerd gekozen, omdat ze meer zal kunnen dan produktie-alleen. De module zal dan ook separaat kunnen worden aangeschaft, en (uiteindelijk) alles kunnen plannen wat met tijdconstraints of andere onderlinge constraints ven doen heeft. E.e.a. al naar gelang wat is gewenst, en in normaal maatwerk te ontwikkelen.

De eerste versie zal werken met tijd afhankelijkheden alsmede materiaal afhankelijkheden tussen Produktieorders/Omvormorders (zowel convergerend als divergerend), en biedt verder alle faciliteiten om uit te bouwen waar gewenst (denk met name aan Resources (machines en mensen), Kalenders en Efficiency).

De Grafische Planning beheert en beheerst alle constraints, en staat toe deze ongelimiteerd multi-level toe te passen (lees : het schuiven met een Order -bijvoorbeeld naar links- zal aan de linkerzijde realtime net zo ver in elkaar drukken totdat alle lag is opgeconsumeerd, en zal alles aan de rechterzijde meenemen voor het volledige model en voor zover bepaald door de afhankelijkheden).

Bij aanvang van het plannen wordt een snapshot genomen van het betreffende deel van de Heart-Profit database;
Gedurende het plannen kan iedere verandering in ongelimiteerde hoeveelheid ongedaan worden gemaakt, en na goedbevinden worden de start-/stoptijden enz. aangebracht in de database.
Te plannen kwantiteiten zijn in principe onbeperkt en alles is voledig schaalbaar/zoombaar voor benodigd overzicht vs. detail.


N.b.: Uit onderstaande screenshots mag volgen dat produktieorders -weliswaar niet tegelijkertijd- op meerdere produktiestations operationeel zijn, wat geen reële voorstelling van zaken is; wel kan een Produktieorder meerdere keren op eenzelfde Produktiestation voorkomen, dan middels Processtappen.
2507  Heart-Profit Boards / Heart-Profit ERP Support / Re: Aantallen niet op de raaplijst on: January 23, 2008, 10:31:53 am
Ook al zijn de gegevens verre van voldoende om deze uitspraak mee te doen : het lijken de voorraad produkten die de mist in gaan. Heb je daar iets aan ?
2508  Heart-Profit Boards / Heart-Profit ERP Support / Re: Alleen verschijnigsvorm verkopen on: January 23, 2008, 10:29:00 am
Ik weet niet of dit een goed antwoord is :

Als je Verschijningsvormen INkoopt, en je zou dat door het systeem laten regelen, dan zul je zien dat een Verschijningsvorm een representant heeft die gewoon een Artikelnummer is. Of meerdere Artikelnummers als de Verschijningsvorm een Embellageset "is".

Hieruit zou volgen dat als je die zelfde Verschijningsvorm (of hele Emballageset) VERkoopt, je alles gewoon al tot je beschikking hebt.

Als dit helemaal niet is te volgen, dan kopen jullie w.s. niet de Emballage automatisch (d.w.z. via de Behoefterun) in. Een kleine cursus is dan wellicht op z'n plaats ?


PS: Mijn schets is maar een voorzetje van waar je in elk geval aan moet denken. E.e.a. houdt niet in dat alles zo maar zal kunnen. Wel denk ik vooralsnog dat jouw "verschijningsvorm" voor een ander (bijv. de producent ervan) niets anders is als een artikel.
2509  Heart-Profit Boards / Heart-Profit ERP Support / Re: Leveren via verkoopkontrakt met maximaal de openstaande kontrakthoeveelheid on: January 21, 2008, 09:51:58 am
Dank je Johan; ik voelde me behoorlijk schuldig en weinig degelijk in dit geval.
2510  Heart-Profit Boards / Heart-Profit ERP Support / Re: CRM-module aanroepen genereert geblokkeerde functie on: January 18, 2008, 02:46:54 pm
Quote
(zit ik al op 254 tekens ;-) ).

Sorry, het mogen er 260 zijn. whistle
2511  Heart-Profit Boards / Heart-Profit ERP Support / Re: Verpakkingsbelasting in DKK? on: January 18, 2008, 02:41:27 pm
Hier een mr. eigenwijs :

In alles zit best wel rechttoe rechtaan logika, met ook gebieden zoals "A hmm ... geen idee, maar B ? nee, dat kan nooit". Voorbeeld is jouw dienstverlening;

Het is wat mij betreft duidelijk dat het niet zo kan zijn dat jouw klant voor die kosten opdraait, immers, er zou geen verschil kunnen zijn met het verkopen van lege verpakkingen (en dat is niet belast). Verkopen is nog erger als "uitlenen", dus als verkopen al mag, mag uitlenen zeker.
Vervolgens ga jij je zooi in die verpakking gieten, en tja, nu be jij formeel de vervuiler. Alleen, is die verpakking ook van jou ? Nee !
Nu wordt het oppassen, want het spul wat erin zit is veelal minimaal deels wel van jou. Ik weet het, dat noem je dienstverlening, maar het is het natuurlijk deels niet. Zie overigens ook je speciale CBS aangifte (goederen vs. diensten).

Als je het laatste toch even buiten beschouwing laat, zie je dat er iets anders sterker is : jouw klant die feitelijk zelf de zooi erin gooit, maar omdat het zo smerig werkje is aan jou vraagt om het te doen.
Als je dit sec leest ben je er ineens uit : Jouw klant moet de belasting betalen. En overigens, zou jij moeten betalen, dan belast je dat wel 1 op 1 door.

Een weer andere invalshoek is wie eigenlijk de "geleverde" tonnages opgeeft. Ik zou zeggen : jouw klant, maar het zou best wel eens zo kunnen zijn dat jij dat doet (en jouw klant dùs niet). Als dit waar is, kom je er formeel niet meer uit, maar klopt er ook iets niet.

Hiermee kan ik de scenario's mooi eindigen, want zo gaat het zo vaak;
Er is uiteindelijk slechts één ding aan de orde : de belasting moet worden betaald. Dat geldt altijd, en dat geldt ook hier. En neem van mij aan (de grote PS zeg maar) dat het feitelijk niet uitmaakt hoe dat voor elkaar komt, als het maar "eerlijk" is, c.q. gebeurt. Ook : die regels zijn er alleen maar om jou en mij te sturen, voor al die gevallen dat het te makkelijk zou zijn om de belasting niét te betalen. Dus, zo strak als mogelijk, maar feitelijk niet met als bedoeling om te worden gewurgd (wat nog wat anders is dan geld uit je zal kloppen, want dat gebeurt toch altijd wèl swoon). Ofwel :

Als jij (ook : wij) onderkent wat er aan de orde moet komen om ergens de belasting te betalen, en je zorgt daar ook voor, krijg jij geen boete en daar durf ik nog wel voor in te staan. Maarrrr, het moet natuurlijk niet zo zijn dat het de basis is dat jouw klant geen zin heeft om die belasting te betalen, jij het niet mag doorbelasten, en je er aldus niet uit komt. Dan heb je regels nodig die er (vast niet) kùnnen zijn, OF (!!!) je wordt gedwongen een regel toe te passen die je niet aanstaat.

Mocht je nog niet helemaal begrijpen hoe ik denk, dan wel het idee hebt dat PS maar wat loopt te blaten, dan kun je je buurman ter rechter zijde eerste straat links bezoeken, en hem vragen hoe het met de BTW is geregeld, wat er allemaal niet kon volgens de regels, en hoe je in goede samenwerking (lees : open staan voor zo'n soort aanpak) tot een oplossing komt waar alle ambtenaren van onder het bureau rollen, en er niets tegen is te doen.
Mocht je het leuk vinden om te vernemen hoe je een kompleet belastingkantoor op z'n kop kunt krijgen (een persoonlijk nogal uitdagend projekt van mij), probeer dan die klant van ons te vinden die begint met een B., eindigt op N., in Apeldoorn huist en toevallig ook de oudste klant is.
FishyFishyFishy

Jaja, die durft. Maar goed, het is mijn lol ook, en overigens niet veel anders als het verhaal rond de EDP auditors.
Om de lol (zoals ik het werkelijk ervaar) tegen te komen, kun je het natuurlijk ook uitlokken, en daarin schijn ik nogal sterk te zijn. Dus wat overkomt mij (onbedoeld) gisteren nou weer ?

Ring ring de postbode. "Ik krijg 45 euro van u". Oh,  waarvoor dan wel ? "inklaringskosten en btw".
Ja maar ... ja maar, wat daar in dat pakje zit is van mij zelf ! "ehh, dat kan niet. U heef het gekocht of het is een schenking aan u; een schenking is trouwens niet zo hoog belast.".

Tja, in de tijd ven emails en alles, hebben ze er toch niet aan gedacht dat er ook nog zoiets kan bestaan als een harddisk ergens heen sturen, dat men er aldaar iets opzet en terugstuurt, en ik het ding toch echt niet nogmaals heb aangeschaft.

Het laatste zeg je als je voldoende onervaren bent op het betreffende gebied, en een ambtenaar aan de lijn krijgt die de regels voorleest. Een ambtenaar overigens die mij óók vertelt dat ik hoe dan ook mijn geld niet terugkrijg omdat ik het pakketje nu eenmaal heb aangenomen. "U had dat beter niet kunnen doen, dan was het vanzelf teruggegaan naar de verzender, en hadden wij het hier bij de douane wel weer tijdig opgepikt". Jaaaa ja.
Hoe dan ook, dingen kunnen zo simpel zijn. Immers, waar gaat het in dit geval fout ? bij de "waarde" die je op dat groene briefje kunt invullen. Nou, nee, eigenlijk gaat het eerder fout : bij die andere ambtenaar achter het loket die voor jou dat briefje erop plakt en die vraagt "wat is het ?" gevolgd door "wat is de waarde ongeveer ?" immers, het groene briefje vraagt erom. En wel ervoor tekenen dat je de waarheid hebt opgegeven !
De oplossing is dus dat je de waarde niet moet opgeven. Immers, over precies die waarde worden invoerrechten en btw geheven. Stommeling. smile

Wel, om een lang vrijdagmiddag verhaal kort te maken : ik denk niet dat het gaat gebeuren dat letterlijk alle regels rond de verpakkingsbelasting kunnen worden gevolgd. Denk voor de aardigheid ook eraan dat als we niet oppassen wij/jullie als enige het probleem hebben omdat toevallig die "verpakking" zo letterlijk wordt onderkend in het pakket. Dit neemt op zich weer niet weg dat waar het pakket ondersteunend (lees : helpend !) kan zijn we dit ook vooral niet moeten nalaten.
Ik zou het er voorlopig maar eens op houden dat je per "order regel" (zowel Verkoop als Inkoop) zelf aangeeft of jij er voor opdraait of niet, omdat het -zeker in eerste aanleg- te moeilijk zal zijn dit geautomatiseerd-juist te bepalen. Er zijn te veel uitzonderingen, en Marco en de dienstverlening is er één van.

Iets anders is dat er tegenwoordig -zo lijkt het- steeds meer dingen worden verzonnen door de overheid die (nog) niet kunnen. Het is misschien dan ook het beste om er gewoon nog even niets aan te doen. Wie weet verdwijnt het probleem vanzelf.
2512  Heart-Profit Boards / Heart-Profit ERP Support / Re: Leveren via verkoopkontrakt met maximaal de openstaande kontrakthoeveelheid on: January 18, 2008, 12:50:17 pm
Quote
Een overhoeveelheid bij het kontrakt lijkt me prima, hoe dit gaat werken icm salderen heb ik nog niet helder. Ik zou me voor kunnen stellen dat dit ook in zeker opzicht per kontraktregel ter sprake kan zijn. Stel je verkoopt 100 ton aardappelen en bieten op 1 kontrakt met 2 kontraktregels, elk 50 ton. Dan zou er bij dat salderen dus niet uitmaken of je nou 70/30 of 30/70 gaat leveren. Staat het salderen uit dan moet je verplicht 50t./50t.  leveren (er van uitgaande dat je de overhoeveelheid op 0 ton /procent hebt staan. )

Hmm ... deze hadden we ook nog. Ga er gerust van uit dat dit niet gaat werken. Of in elk geval niet voor de zes uur.

Nu blijkt er nog wat anders aan de knikker :
Ik had gedacht dat e.e.a. alleen voor Bulk behoorde te werken, en op zich is dat denken we ook wel zo, alleen, er is meer dan Bulk leveren zoals jij dat doet ... Dus (ook al is het nooit zo konkreet uitgesproken) je kunt ook aan de deur Bulk leveren, maar dat is andere funktionaliteit. Maarrrr, dat brengt mensen hier ook op het volgende :

Als je kijkt naar hoe het Leveren van "voldoende" in elkaar zit - en denk nu juist even aan Niet-Bulk - dan zie je dat het gaat om het aantal Verschijningen. Nooit om de hoeveelheid Voorraad Eenheid. En nu komen we er ineens niet meer uit met 6 uur ... (buiten dat hoogstwaarschijnlijk ook jij dit wilt toepassen op Niet-Bulk spulletjes !).

Aan de Leverkant blijkt het te ondoenlijk om alleen Bulk te behandelen omdat zaken te veel door elkaar lopen en er momenteel eigenlijk nergens iets in zit wat je tegenhoudt van "te veel" Leveren (dat mag je namelijk zelf weten -> als dat administratief zo wordt verwerkt is het kennelijk ook gebeurd en was het kennelijk ook nodig, MAAR zie het verschil met aan de deur leveren en bij de klant leveren). Zie nu ook nu het verschil tussen 10 ton leveren, en 20 big bags met een inhoud van 1000 Kg versus een inhoud van 800 Kg. Ook die 20 x 200 is te veel leveren, maar Profit vindt dat niet. Het is toch wel 4 ton ...

Samengevat, om dit allemaal op juiste wijze te ondervangen komt er helaas 8 uur bij, en zie dan ook nog het begin van deze post wat er dan nog niét in zit.
N.b.: Er zitten al uren in, maar als je het nu niet meer wilt is dat pech voor ons.

sorry
2513  Heart-Profit Boards / Heart-Profit ERP Support / Re: CRM-module aanroepen genereert geblokkeerde functie on: January 18, 2008, 11:48:05 am
Nou, de tomaten zitten in m'n nek.

Antwoord : Ja.

En laat ik dat nou helemaal niet (meer) weten ...
Sorry hoor.  oops
2514  Heart-Profit Boards / Heart-Profit ERP Support / Re: CRM-module aanroepen genereert geblokkeerde functie on: January 18, 2008, 11:15:05 am
Ehh Johan, betalen jullie onderhoud hiervoor ?

Tomatos
2515  Heart-Profit Boards / Heart-Profit ERP Support / Re: Gegevens worden fout overgenomen on: January 18, 2008, 09:24:15 am
Quote
Wat mij betreft moet de vraag "Genereren Variabelen" weer terug.

Ik denk dat je daar veel mensen blij mee maakt.
2516  Heart-Profit Boards / Heart-Profit ERP Support / Re: LOVRVIGN werking per charge niet wenselijk on: January 17, 2008, 09:21:51 am
Reden 1 : omdat dat zo hoort bij dit soort veranderingen.
Reden 2 : omdat je het niet fout moet kunnen doen en de default niet anders mag zijn dan de momentele werking.

2517  Heart-Profit Boards / Heart-Profit ERP Support / Re: Vastloper in LOARRECB on: January 17, 2008, 08:42:29 am
Toch maar even naar kijken ?

Zo ja, laat dan meteen de inhoud van de geblokkeerde funktie zien.
2518  Heart-Profit Boards / Heart-Profit ERP Support / Re: Vastloper in LOARRECB on: January 17, 2008, 08:37:37 am
Misschien heb ik dat wel geweten, maar ik heb echt geen idee nu.

Ook al is de programmatuur niet door ons geschreven, het zal heus wel meevallen met de kosten, en we hebben de sources natuurlijk ook niet voor niets gekregen (namelijk, om in gevallen zoals dit te kunnen helpen).

Als het meer dan 3 uur gaat worden, zien wij dat op voorhand en melden dat (en dan kun je nog wel onderzoekskosten van een half uur hebben).

Hoe dat met dat onderhoud moet weet ik niet, want ik kan niet iedereen dwingen dat te nemen. En als jij het in je eentje hebt, heb ik in 3 uur het geld erdoor gejaagd (zo zijn wij wel) terwijl voor de (niet betalende) rest ook het probleem is opgelost. Ik weet het, dat laatste gebeurt nu ook, maar dan zijn onze kosten tenminste vergoed.

Ik wil er verder niet te veel woorden aan vuil maken.
2519  Heart-Profit Boards / Heart-Profit ERP Support / Re: Vastloper in LOARRECB on: January 17, 2008, 08:14:30 am
Nope. Maar dat wist je al wel.

Nou ja, kan wel, maar dat zal wel grof geld kosten (je hebt hierop geen onderhoud).

Tip : maak een nieuw recept. Ander prdukt. derisive
2520  Heart-Profit Boards / Heart-Profit ERP Support / Re: LOVRVIGN werking per charge niet wenselijk on: January 17, 2008, 08:06:27 am
Quote
Zeg maar wat het gaat kosten om de gehele voorraad op de palletlokatie naar de raapvloer te verplaatsen.

Een Bedrijfsparameter.

Quote
Ik vind het allemaal een beetje kort door de bocht.

Dat is toch niet waar, want alleen ik al heb 4 uur hieraan besteed gisteren en eergisteren. Menno ook (nee, meer) kan ik je zo vertellen, en Wouter ook nog een paar.

Voor de rest bemoei ik me er niet mee. swoonswoonswoonswoonswoonswoonswoonswoon
Pages: 1 ... 138 139 140 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 ... 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.23 seconds with 12 queries.