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

Login with username, password and session length
News:
 
  Home Help Login Register  
  Show Posts
Pages: 1 ... 131 132 133 134 135 136 137 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 ... 273
2401  Heart-Profit Boards / Heart-Profit ERP Support / Re: Tonen "HERKOMST" bij artikel on: February 22, 2008, 11:33:57 am
Quote
maar als ik Peter goed begrijp komt dit gewoon als optie "S" in het artikelmenu te staan: "mogelijke Landen van herkomst" welke gekoppeld is aan die iso-landkodes.

Nee, sorry. Ieder "land" zijn eigen Artikelnummer, met in principe een tekst veld voor de Herkomst.
Achter dit "tekst" veld zou op zich een tabel met de mogelijkheden kunnen hangen, maar dat lijkt mij wat overdreven.
In dit tekstveld kan uiteraard NL-FR komen te staan. Let wel, als dat FR al nodig is, omdat het produkt zelf denkelijk voldoende beschrijvend is (?). Maar dat kan iedereen zelf kiezen natuurlijk.
2402  Heart-Profit Boards / Heart-Profit ERP Support / Re: dkk op land vereist dubbele invoer? on: February 22, 2008, 11:26:05 am
We hebben het even uitgezocht. Werkt niet bij Inkoop (kan denk ik wel gemaakt worden, maar denk eraan dat dit aldaar zaken betreft die wellicht niet zo gemakkelijk eenduidig in Profit zijn te bepalen, zoals bijvoorbeeld het verzenden van een Magazijn "ergens" naar een klant "ergens" wel kan). Maar goed, misschien 7 uur of zo ?
2403  Heart-Profit Boards / Chat / Re: Sorbet en land van herkomst on: February 22, 2008, 10:38:45 am
rofl
2404  Heart-Profit Boards / Heart-Profit ERP Support / Verpakkingbelasting ook per gewicht ? on: February 22, 2008, 10:37:51 am
Ach, nog maar een topic hieraan besteed ...

Begrijp ik het nou goed dat e.e.a. ook afhangt van het gewicht ? Bijvoorbeeld :
Je hebt een "plastic" IBC, maar met daaromheen een metalen kooi. Hoe zwaarder (en dus veiliger) die konstruktie, hoe hoger de belasting.

Is dit juist ?
(heb geen zin om het zelf uit te zoeken; ben ook maar een stadsjochie).
2405  Heart-Profit Boards / Heart-Profit ERP Support / Re: DKK tarieven definitie on: February 22, 2008, 10:35:34 am
Quote
Je betaald dus zowel bij verwerving als bij verkoop belasting

Waar haal jij dit uit ? en wat is de logika erachter ?
2406  Heart-Profit Boards / Heart-Profit ERP Support / Re: Tonen "HERKOMST" bij artikel on: February 22, 2008, 10:31:13 am
Het is best goed om mee te denken. Dank ...

Van mijn kant zal ik proberen de problematiek wat helderder te krijgen ... wie weet brengt het nog wat tijdens het typen ...
Demis is toch een weekje weg dus we kunnen hier rustig van alles in elkaar draaien voor hem. Aan het eind zal het resultaat wel staan ...

Zie ook deze post uit de link waar Dirk-Jan naar verwees, en die feitelijk handelt over produkt van Johan. De betreffende reaktie daar van Wouter is ogenschijnlijk gelijk aan zijn reaktie hier, maar de context is anders, en daarmee de reaktie feitelijk ook. Immers :

Wat in die post al staat is dat je je op een gegeven moment moet afvragen of het (stel nu maar eens) graan uit België hetzelfde produkt kwa kwaliteit is als graan uit Nederland. "Jahaa" zegt Johan, "dat maakt ons niet al te veel uit als eenmaal aan een basiskwaliteit is voldaan, want wij maken er zelf tòch altijd dezelfde (produktie) kwaliteit van !".

En zo zie je al een verschil met de tomaat ontstaan;
Het graan uit België is zeker weten niet gelijk aan het graan van Nederland (de verschillen bevinden zich al op teler gebied). Maar, op "de e.o.a." manier weet men de kwaliteit als gelijk te brengen (van de verkoper uit), dan wel als gelijk te zien (van de inkoper uit). je voelt wel, hieruit volgt maar één resterende mogelijkheid : de verschillen -die er overigens per partij al zijn- op partij (Charge) niveau vastleggen. De eigenschappen van de Charge. Petje af voor Wouter ... helemaal goed (maar ook doodmakkelijk als je mij ziet beredeneren dat er geen andere mogelijkheid is).

Nu de tomaten.
Uit eigen ervaring kan ik je vertellen dat de ene tomaat nog rotter is als de ander. Werkelijk, de tijd dat tomaten super lekker waren stamt uit de tijd dat ik ze zelf plukte om 04:30 'smorgens, met zelf meegebrachte muziek op cassette wat wel een hoge dosis Deep Purple, Uriah Heep en Black Sabbath zal hebben gehad. Nee, wij hoefden toen geen pools te praten.
Kortom, als ik tegenwoordig bij de Plus sta (wie doet dat ook), dan wil *ik*, ja IK al weten waar die dingen vandaan komen, anders zijn op zaterdagavond als eerste de enkele van de zelfgebakken zachte puntjes al weer naar de knoppen.

Kortom, we hebben het hier niet meer over "eigenschappen" van een gedefinieerd produkt als "basis" (!) maar over een ander produkt, wat zich goeddeels al laat omschrijven doordat het bijvoorbeeld uit Spanje komt. De zon zit erin, en blablabla. Daarnáást is iedere partij nog een keer anders, en dat begint al bij de houdbaarheid. Dwars daar doorheen voor een tomaat ook nog de kleur.
Eigenlijk is het voor een tomaat wel duidelijk : die bestaat in vele Artikelnummers en klassen, en je zou 'm nog kunnen beschrijven via z'n Eigenschappen.
En oh ja, vergeet niet dat een tomaat binnen de grootbeschrijvende Herkomst nog het uitgelegde principe van het graan bevat. Immers, je kunt een groene net zo lang laten liggen tot 'ie bijvoorbeeld oranje is, en de snelheid (daarmee de kwaliteit) waarmee dit gebeurt kun je beïnvloeden..

Opmerking terzijde, wat denkelijk ook met de problematiek van dit topic van doen heeft :
Profit kan tegenwoordig -en niet voor niets- 95% omgaan met het vervangen van produkten op allerlei niveaus (zoals Goederen Ontvangst, Produktie, Leveren). Wel gebeurt dit eigenlijk alleen bij Touch Screen en Scan funktionaliteit. Er is zelfs funktionaliteit om een tomaat van groen naar oranje en van orranje naar rood te laten kleuren, waarbij dit eigenlijk allemaal verschillende artikelnummers zijn. Dwars daar doorheen kunnen klassen op dezelfde wijze worden aangepast. Ook die veranderd met de tijd (van het fysiek zelfde produkt).

Maar nu komt de ellende; Nu komen de druiven.
Druiven placht je in te kopen uit het land waar ze gewoon "goed" zijn op dit moment. E.e.a. uiteraard gehouden tegen de kwaliteit die je je klant wil voorschotelen. Dus bijvoorbeeld -niets aan te doen- de druiven van Dirk vd Broek zullen minder zijn dan de druiven van de Hanos. Mag ook best, want de Dirk klant heeft er minder geld voor over dan de restauranthouder van Hanos.
Ook hier wil de klant nog steeds weten uit welk land ze komen, omdat het wederom bepalend is voor een basis kwaliteit (misschien beter : -smaak). Welnu, zoals Demis het stelt "ze komen iedere keer uit een ander land, en wij bepalen welk land dat is". En ... als je nú daarvoor aparte Artikelnummers maakt (Eigenschappen is dus niet juist), heb je dus een Assortiment van 20 verschillende druiven terwijl je er altijd maar 1 aan boord hebt.

Voor Demis is het nu lastig dat er via de Webshop wordt besteld. Nee, niets aan de hand met het onwerkelijke Assortiment, want dat is wel geregeld (19 druiven Artikelen zijn Inaktief). Maar ... men werkt met Bestellijsten, en daarop staat het Artikelnummer van de druif. Nou ja, één Artikelnummer van één druif. En je voelt wel, als de inkoper bij Demis zin heeft om de druiven voor morgen uit Zambia te laten komen, mogen alle instellingen kun Bestellijsten aanpassen. En dat werkt dus niet ...

Waar je m.i. naar toe moet is -in het druif geval- inderdaad één Artikel, waarbij om te beginnen een kolom Herkomst als "niet altijd aktueel" moet worden gezien. Dus, je doet je best om het juiste land te tonen, maar als de druiven uit Zambia een dag te laat komen, haal je ad-hoc om de hoek bij een collega, en die heef ze nu juist uit Spanje gehaald.
Omdat een klant niet weet bij welke produkten dit zo kan optreden, en het bij de tomaten zich verdeelt over verschillende Artikelnummers waar je óók een Herkomst wil zien, mag er denkelijk ook een indikator "kan veranderen !" bij. Dit om reclamaties achteraf te voorkomen.

Maar nu het volgende :
Waar het Assortiment één druif (Artikelnummer) kan tonen (omwille van het gemak van de Bestellijsten èn het minder belangrijk / onmogelijk zijn om te leveren uit landen zoals gevraagd (je zou maar uit 20 landen tegelijk moeten betrekken), kun je nog wèl zelf 20 Artikelnummers hebben ... Ieder met z'n eigen Herkomst ingevuld, en die in dat geval vast is. Ofwel, je hebt die 20 Artikelen, plus dat ene dat "variabel" is, speciaal voor de internet bestellers.

Nu komen de druiven binnen, en we krijgen daadwerkelijk druiven uit Zambia binnen (hebben ze daar wel druiven ?);
Alle Orderregels voor "druiven" moeten nu worden omgezet naar "druiven uit Zambia" (de Artikelnummers veranderen). Dit betreft dus het eerder aangehaalde deel van wat het systeem expliciet kan. Bij Levering wordt dus iets anders geleverd dan gevraagd.

Waarom moet dit nu op deze wijze ?
Wel omdat de druiven uit Zambia een andere prijs hebben, door andere telers (of leveranciers) wordt geleverd, en wat al dies meer zij wat je zou willen terugzien in statistieken. Zou je maar één Artikelnummer ervoor hebben, dan kan dat natuurlijk nooit.

Om een lang verhaal kort te maken : Naast dat het laatstgenoemde m.i. moet gebeuren om het goed te doen (en je uiteraard dan ook kunt zien waarvan je voorraad hebt wat met iets als Eigenschappen beremoeilijk wordt), betreft het fenomeen "Herkomst" een daadwerkelijke property van het Artikel. Het beschrijft op hoog niveau wat anders alleen met veel te veel woorden kan worden beschreven, en in de supermarkt zou ik dáár juist niets aan hebben. "Spanje" zegt mij genoeg en i.h.a. alles.
Dus dit veld moet erbij (Artikelniveau). Zoals al aangegeven, ook een indikator of verwacht mag worden dat het bij Levering anders is. Dit heeft dus te maken met het "variabele" ene Artikelnummer voor de druif, waarbij je wel steeds zo goed als mogelijk de Herkomst verandert. Een "druif uit Zambia" zal deze indikator op Nee hebben staan, want een druif uit Zambia komt nu eenmaal uit Zambia, en als ik die zou kunnen bestellen behoort dat niet te veranderen. Het kàn natuurlijk nog wel, maar het is niet de bedoeling.
Aldus heeft die indikator ook logistieke werking, want ze zal er op z'n minst voor moeten zorgen dat indien op Nee het minder makkelijk is om de VORegels in deze te veranderen naar een vervangend produkt.

Laatste opmerking : het systeem weet welke produkten door anderen kunnen worden vervangen. De variabele druif heeft zodoende 20 anderen aan zich hangen als vervanger.
Overigens zou ik een schol uit Urk niet vervangen door aan schar uit Azië. swoon
2407  Heart-Profit Boards / Heart-Profit ERP Support / Re: dkk op land vereist dubbele invoer? on: February 22, 2008, 09:22:04 am
Het is zoals Wouter zegt. Het Tarief leg je op de kombinatie.
Wat mij betreft is dat voor de Verkoopzijde ontwikkeld, dus of dit ook aan de Inkoopzijde zo maar werkt ... zelf even uitproberen ?
2408  Heart-Profit Boards / Heart-Profit ERP Support / Re: DKK tarieven definitie on: February 22, 2008, 09:19:27 am
Klinkt in elk geval goed als "een basis" Marco. Voor jouw (ieders) info ook even dit :

Op dit moment wordt er zwaar gesleuteld aan Verkoopprijzen die Land-uniek kunnen worden gemaakt. Dit wordt in praktisch alle Prijsregistraties ingebouwd. Ofwel, je kunt netjes (ook per Verschijningsvorm) de Verkoopprijs maken (middels een Opslag die op de Verschijningsvorm rust).

Dit zou je denkelijk precies zo met een DKK (Opbrengstverhogend) kunnen doen, maar ik kan me niet aan de indruk onttrekken dat een DKK "anders" is in deze (denk aan de Faktuur).
2409  Heart-Profit Boards / Heart-Profit ERP Support / Re: Print recept adhv verliesfactoren on: February 22, 2008, 09:12:56 am
swoon

Nou, dan houd ik de discussie toch wel levend door eigenlijk niet toe te staan dat dat veldje er wel komt en de PO niet zou worden aangepast. Wat mij betreft past dat niet bij elkaar, en gaan er ook werkelijk zaken fout. Hooguit kan ik je er toevallig niet van tegenhouden, omdat je PO betaald moet worden aangepast. Wat ik echter wèl kan doen is dat ene veldje niet maken ...

Als je het er niet mee eens bent moeten we het eerst maar verder uitwerken. Toch ?

N.b.: Wat jij weer niet weet -en waar ik onvoldoende aan heb gedacht- is dat het weer (te !) makkelijk gegeven voorbeeld van verdampen hier al is besproken (wat moeten we ook anders verder doen als we niet aan het typen zijn). En, het resultaat van het "ontwerp" daarin, is dat je als gebruiker nu zelf kan kiezen per produkt hoe jij het vindt (dat het moet uitwerken). Wij zijn er dan vanaf. Dus :

Waar jij met pasta komt als *het* voorbeeld wat in elk geval nooit met verdampen te maken heeft, kom ik gewoon met verdampen, echter met de context (die ik niet noemde) dat als spul verdampt je er donder op kunt zeggen dat juist de gevaarlijke troep overblijft (er vanuitgaande dàt er troep over blijft). Dus inderdaad, als je spulletje volledig verdampt zit het er vervolgens niet in (MSDS), en als je het er nooit in gooit (pasta aan kuiprand e.d.) eveneens niet. Je kunt je echter afvragen (en ja, jij hebt ervoor geleerd) en hoeveel gevallen er inderdaad he-le-maal niets overblijft na verdamping. Gokje van mijn kant : nooit. Tenzij het puur water betreft waarvoor wel een goede naam zal bestaan (gedestilleerd water ? hahaha). En nogmaals, wat er dan overblijft is 100% van de troep die er met het grotere volume net zo goed al in zat.

Nogmaals, door gewoon de rubriek ter beschikking te stellen, kan iedereen per grondstof kiezen hoe hij vindt dat het moet uitwerken. Ons maakt het dan niets meer uit. Als het stuurmiddel er maar is.

Over ...
2410  Heart-Profit Boards / Heart-Profit ERP Support / Re: DKK tarieven definitie on: February 22, 2008, 09:00:44 am
Als we nou gewoon alle goede en nuttige ideeën op een rijtje hebben (wat op dit moment dus eigenlijk niet kan) dan maken wij het, formeren het in e.o.a. 800 euri Basisprijs module en kunnen we best het e.e.a. doen ...

In dit ietwat uitzonderlijke geval lijkt het me niet de bedoeling dat één klant een DKK voor z'n rekening neemt en de rest er kosteloos lekker mee gaat werken, waar iedereen heel duidelijk de behoefte heeft.

Tot een gedegen opzet "kosten verdelen" zijn we tot op heden nooit gekomen (w.s. omdat ik denk dat dat niet gaat werken -> te veel gedoe en gepraat en "maar dat wil ik niet en wil ik dus ook niet voor betalen"), maar e.e.a. domweg in een module vatten werkt natuurlijk wel. Nou ja, denk ik.

Overigens denk ik dat er heel, heel veel moet gebeuren als je straks alles lekker geautomatiseerd wil aankunnen. Dat behoort niemand in z'n eentje te betalen (vooral ook wij niet, haha).
2411  Heart-Profit Boards / Heart-Profit ERP Support / Re: Print recept adhv verliesfactoren on: February 21, 2008, 03:41:23 pm
iedereen tot op heden "binnen" de Order het verlies had. Anders zouden ook alle MSDSsen verkeerd zijn geweest.  Wink

Overigens niet onwettig, immers, de MSDSsen zouden "te gevaarlijk" aangeven. Anders hadden we wel aan een grotere bel gehangen. yes
2412  Heart-Profit Boards / Heart-Profit ERP Support / Re: Print recept adhv verliesfactoren on: February 21, 2008, 03:36:19 pm
Dit heeft niets met de beschrijving (helptekst) te maken Marco. Er is gewoon tot heden nooit iemand geweest die eraan heeft gedacht dat er in deze onderscheid bestaat. MAAR : als er één konklusie mag worden getrokken met hoe "men" hiermee dan om zou moeten gaan, is het het "verdampen" verhaal.

Nogmaals :

Quote
Het Produktie-uitval percentage is een hoeveelheid grondstof die bij de Produktie verloren gaat, b.v. ten gevolge van morsen of om ndere redenen.

Dit geeft al aan dat het ons en niemand wat uitmaakt welke soort verlies het betreft ...

Maar nu kom jij met jouw verhaal, en ook jij hebt het niet door (had, natuurlijk). Er blijkt namelijk wel degelijk verschil, en het eerste waar dat zich uit als je expliciet (!) doet wat jij doet, namelijk "morsen" zeg maar, dan klopt je MSDS niet.
Dat je dan ineens óók het probleem hebt van het feitelijk niet weten (operator) of je 50 of 55 in de kuip moet gooien, is weer een ander probleem, maar wel veroorzaakt door hetzelfde fenomeen : er is onderscheid. E.e.a. zoals nu omschreven : verlies buiten de PO is iets heel anders als verlies binnen de PO.

Heel eerlijk gezegd benaderen we het dus zo dat waar niemand hierover heeft geklaagd (let wel, jij eigenlijk ook niet), het *dus* maar zo moet zijn dat iedereen tot op heden "binnen" de Order het verlies had. Anders zouden ook alle MSDSsen verkeerd zijn geweest.  Wink
2413  Heart-Profit Boards / Heart-Profit ERP Support / Re: foutmelding printen klachten on: February 21, 2008, 03:24:48 pm
Gert, het spijt ons, maar het gaat niet lukken.
Als het mee zit wel morgenochtend vroeg. 07:00 of zo. Mocht je daar iets aan hebben, zorg er dan in elk geval voor dat tegen die tijd je modem enz. klaar staat. Dit op zich overigens weer zonder de garantie dat het overgestuurd kan worden zonder upgrade. Want anders ...
2414  Heart-Profit Boards / Heart-Profit ERP Support / Re: foutmelding printen klachten on: February 21, 2008, 02:25:07 pm
Dan hoop ik maar dat dàt lukt. Ik zou er niet direkt op rekenen ...
2415  Heart-Profit Boards / Heart-Profit ERP Support / Re: Print recept adhv verliesfactoren on: February 21, 2008, 02:21:31 pm
Hahaha, Marco ... je mag onze interne verslaggeving ook wel lezen hoor. We zijn op deze oplossing (beter : het werkelijke probleem) gekomen, juist door de MSDS die anders (op onnavolgbare wijze) niet zou kloppen. Alleen al daarom is laatst genoemde J/N rubriek NOODZAKELIJK.

Verder vindt je als het goed is alles terug in mijn betoogje. Dus lees het s.v.p. nog eens nu je weet dat wij daaraan hebben gedacht, en reageer dan nog eens.
N.b.: Het MSDS verhaal hoeft niemand te betalen, want dat vonden wij te ver gaan. En, ik noémde het niet omdat het iets van "slapende honden wakker maken" in zich heeft. Maar goed, nu jij het toch bekend hebt gemaakt ... als je werkt zoals jij werkt (v.w.b. de pasta) dan klopt je MSDS dus ook mooi niet (als die uit Profit zou komen)).

Maar schiet gerust nog eens terug. smile
Pages: 1 ... 131 132 133 134 135 136 137 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 ... 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.164 seconds with 12 queries.