Heart-Profit ERP
July 06, 2024, 11:15:12 am *
Welcome, Guest. Please login or register.

Login with username, password and session length
News:
 
  Home Help Login Register  
  Show Posts
Pages: 1 ... 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 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 ... 273
2086  Heart-Profit Boards / Heart-Profit ERP Support / Re: kredietlimieten en geblokkeerde orders on: June 26, 2008, 09:44:38 am
Dat wordt niets zo ...
2087  Heart-Profit Boards / Heart-Profit ERP Support / Re: Direct versturen Orderbevestigingen on: June 26, 2008, 09:32:54 am
Ja, dat was wel mij bedoeling fool
Wordt intussen iets anders, want nu moet ik ergens het email adres van "jou" kwijt voor de kopie.
En we waren nog niet helemaal klaar natuurlijk.

Kijk intussen eens naar onderstaande, en probeer eens of de manier waarop dat werkt je bevalt. Vergeet niet na het printen de Verkooporder weer te wijzigen ...
(heeft natuurlijk niets met EMAILEN te maken)
2088  Heart-Profit Boards / Heart-Profit ERP Support / Re: Direct versturen Orderbevestigingen on: June 26, 2008, 09:18:39 am
EDI lukt wel met een uur of of 6.

NOU MOE ! Nou heb ik al een keer EDI gelezen terwijl het er niet stond, maar als klap op de vuurpijl schrijf ik het ook nog terwijl ik het niet wil.

email email email email email email email email email email email email email email email email email email email email email email email email email email email email email email email email email email email email email email email email email email email email email email email email email email email email email email email email email email email email email email email email email email email email email email email email email email email email email email

swoon swoon
Not so fast man ...
2089  Heart-Profit Boards / Heart-Profit ERP Support / Re: Direct versturen Orderbevestigingen on: June 26, 2008, 08:31:44 am
Dat printen is dan naar een faxpoort, waarna je 'alleen' nog zelf het faxnummer in moet geven. (m.a.w. Je hoeft niet per se een papieren uitvoering van je orderbevestiging om te kunnen faxen).

Dit is natuurlijk helemaal juist. Dus :
Dit betreft het verhaal van de popup (waar schreef ik dat ook alweer ?) wat Windows zelf standaard kan (WinFax ?) en anders wat "alles" wel kan. Dus inderdaad, als je tòch het faxnummer een keer moet intypen, kan je het misschien maar beter zo doen ook. Je bent dan in elk geval volledig onafhankelijk van ons (geen expliciete interface), en je print gewoon naar een "printer" (of Queue) net als bij een gewoon printje.
2090  Heart-Profit Boards / Heart-Profit ERP Support / Re: Printen DKK tarieven print geen staffels on: June 25, 2008, 01:21:28 pm
Tja, da's een grap ...
Op "Overzicht Tarieven DKK" staat de basis DKK er natuurlijk wel bij, maar het onderscheid naar de Staffels niet.
Ik denk dat dit in diezelfde print wel erbij mag (plus vinkje om het al dan niet aktief te maken). 3 uur, en dan maar hopen dat de gegevens enigszins adekwaat kunnen worden weergegeven, wat ik me op zich nog afvraag. Immers, die Staffels zijn feitelijk bedoeld voor iets wat impliciet werkt, wat ik ook niet goed onder woorden wil brengen. Maar denk er maar aan dat je wellicht eigenlijk per Debiteur/Afleveradres de uitwerking wilt zien (Prijsfaktor), wat natuurlijk onzin is voor zo'n print. Dus dat daargelaten, denk je dan dat je er iets aan hebt ?

LOPRDKVE heb ik niet naar gegeken (in de snelligheid geen idee waar dat zit).
2091  Heart-Profit Boards / Heart-Profit ERP Support / Re: kredietlimieten en geblokkeerde orders on: June 25, 2008, 01:10:47 pm
Eigenlijk is het (dan) zo dat je (formeel dus) van een Verkooporder voor over een maand niet kan weten of per dan de Kredietlimiet overschreden zal zijn. Dit zou een "aantal dagen" vergen, met daarin bijvoorbeeld 5, en waarbij die 5 afgaat van de Leverdatum om vervolgens pas op die Leverdatum - 5 te gaan kijken of de Kredietlimiet (nog of intussen !!) is overschreden.

Klinkt leuk ? Ja. Maar het werkt denk ik niet gezien de ontbrekende voorziening om de impliciet verstrijkende tijd zijn werk te laten doen.
Het is ook verre van makkelijk als je bedenkt dat dat aantal dagen op (stel) -5 staat, maar jouw procedure zo is dat je 10 dagen vooruit inkoopt (of het systeem dit domweg doet gezien een betreffende Levertijd) en je dus intussen spullen hebt ingekocht voor iets wat je wellicht voorlopig niet (of nooit) gaat leveren.
Tja ...

Ik ga maar eens een poging ondernemen om te stellen dat wat je doet niet helemaal lekker is (lukt me misschien niet hoor, maar ik probeer het in elk geval);

Ik wil niet zeggen dat wat je hier doet riekt naar Afroepen, maar het lijkt op z'n minst iets als een Kontrakt te behelsen. Zijn we daarmee geholpen ? nee, ik denk het niet, althans, niet bij de manier waarop het systeem momenteel werkt. Wèl geldt het volgende :

Als je dit ziet als een soort van Afroep (c.q. Kontraktwerking), dan zie je in elk geval dat die Afroep een expliciete aktie is, die je als trigger mag zien voor het gaan bekijken van de Kredietlimiet. Dus, zie iets voor je van het op het juiste (betreffende) moment opnemen van de Verkooporder, die dan - gelijk de andere normale Verkooporders - hun werk aangaande de Kredietlimiet echt wel doen.
We hebben nu niets te maken met de Behoefterun (kan niets te vroeg doen) en de Kredietlimiet van dat moment moeten we maar als aktueel zien (maar, kan net zoals altijd nog wachten op dat ene faktuurbetalinkje).

Aannemend dat ik nog een beete op een spoor zit waarmee je kunt leven, gaat het er dus nog slechts om hoe we het geheel (ook jullie) zo ver krijgen dat je die Verkooporders pas gaat inbrengen op het moment surpreme;

Een Kontrakt met Afroepgedachte werkt wat mij betreft 100%, maar vereist dan ook wel dat de klant op een gegeven moment weer belt met "ja, nu graag !".

Is dat zo in jouw geval ?
2092  Heart-Profit Boards / Heart-Profit ERP Support / Re: Direct versturen Orderbevestigingen on: June 25, 2008, 12:36:46 pm
Ja, dat laatste heb je wel goed gezien.
Zullen we niet beter gewoon een button neerzetten die e.e.a. op jouw commando doet ? ... aangevuld met een duidelijke indikatie in de Raadpleegfunkties (zoals LOVORA) dat de Orderbevestiging nog niet de deur uit is ? Als er dan iets aan de Verkooporder wijzigt kan die indikatie worden gereset, en kan je de button nogmaals gebruiken ...
2093  Heart-Profit Boards / Heart-Profit ERP Support / Re: Klachtomschrijving bij retourzending aan Leverancier on: June 25, 2008, 09:55:12 am
En wat moet de leverancier nou met een klachtkode ? Ik bedoel, dit zal toch wel *jullie* klachtkode zijn ?
Of anders gezegd : wil je niet liever de omschrijving van de klachtkode afgedrukt hebben ?
2094  Heart-Profit Boards / Heart-Profit ERP Support / Re: Klachtomschrijving bij retourzending aan Leverancier on: June 25, 2008, 09:53:11 am
Klopt het dat je het nog steeds zo wilt als onderstaand ?
2095  Heart-Profit Boards / Heart-Profit ERP Support / Re: Direct versturen Orderbevestigingen on: June 25, 2008, 07:54:02 am
Ok.
Maar ja, hoe moet dat "direkt" nou ?

Denk er in deze aan dat als direkt te direkt blijkt (want later wil je alsnog iets toevoegen aan de order) de orderbevestiging de deur al uit is en ontvangen ...
2096  Heart-Profit Boards / Heart-Profit ERP Support / Re: Direct versturen Orderbevestigingen on: June 24, 2008, 03:25:04 pm
Nu je dat zo vraagt, dat weet ik niet goed. Wat mij betreft natuurlijk Kontaktpersoon (als die er is, en anders algemeen), maar het is nog niet gezegd dat "de" Kontaktpersoon degene is die je hier wilt adresseren.

We hebben zoiets nog niet eerder gedaan (want het is een beetje raar en niet juist "genormaliseerd") maar ik denk nu aan net opnemen van een veldje "Kontaktpersoon Offerte J/N" bij de Kontaktpersoon zelf (en er zouden meerdere van dat soort veldjes kunnen ontstaan). Ofwel, naar iedere Kontaktpersoon bij de betreffende Relatie waar dit veldje op Ja staat, gaat de email met de Offerte naar toe.
Ik zeg al, een beetje raar, maar het lijkt me wel te mogen (en zeker lijkt het wel te werken -> je kunt er dan ook meerderen aanwijzen).

Is dat wat ?
2097  Heart-Profit Boards / Heart-Profit ERP Support / Re: Keuringsrapport tekst afdrukken afhankelijk van artikel(/groep) on: June 24, 2008, 03:19:24 pm
Ik denk dat jouw humeur intussen dusdanig is ingezakt dat *IK* een weekje niet meer reageer op iets van jou. Je mag het met de rest doen waar mogelijk, en achter de schermen keur ik wel af waar nodig. Dit is dus voorlopig het laatste :

Ik weet werkelijk niet waarover je het nu hebt. Maar misschien als je naar mijn laatste post kijkt dat je zelf een misverstand (aan jouw kant) ziet ? Het lijkt me dat je de allereerste zin in die post niet hebt gelezen en daardoor denkt dat ik over jouw (in de eerste quote) "nederlandstalige tekst" versus (in de tweede quote) "die afhankelijk is van een taalkode" val ? Neen ...

Waar ik over val is dat je het over een (eerste quote) "hele serie artikelen" versus (tweede quote) "en een artikel" hebt, en waarbij je dus "1 iets" wat bij meerdere artikelen hoort redundant gaat opnemen bij meerdere artikelen. Het was je eigen onderwerp ...

Het was je eigen onderwerp met een konklusie voor een oplossing die ik niet zou willen. Hoe je dit weet te verdraaien naar :

Quote
Nou vat ik, speciaal voor jou, een hele uiteenzetting over het probleem samen in 1 conlusie, is het weer niet goed. De ene keer mag ik geen toelichting geven, de andere keer moet de vraag duidelijker met een toelichting, wanneer is een vraag nu wel goed?

is mij een raadsel.

Quote
In de tweede post, in de conlusie dus, heb ik dat nog rechtgezet. Ik noem daar dat het afhankelijk van taalkode is. Kun je je dan nog niet voorstellen dat ik diezelfde tekst ook meertalig beschikbaar wil hebben?

Ooh ja: de vertaling van die tekst lever ik zelf wel aan. Zelfs daar hoef je je niet druk om te maken. Ik wil alleen weten, waar ik deze lap tekst op een zodanige manier kwijt kan, dat ze aan te roepen is op het keuringsrapport welke middels die variabele layout wordt afgedrukt.


Twee keer fout dus, alleen omdat je (denk ik toch) één zinnetje niet leest. En mocht het lichtblauw van de link niet goed doorkomen ... die verwijst naar wederom het onderwerp van de meerdere talen en hoe dat te doen, plus dat ik daarin noem hoe je teksten bij een Artikelgroep (Eigenschappen daarin) kwijt kunt. Dat je in dat topic -geheel separaat- niet het antwoord op dit topic leest, tja, dat lijkt me te wijten aan je humeur of instelling.
Dat het geheel nu over twee topics is verdeeld is overigens je eigen schuld.

Zo, ik stop er nu dus even mee; doe maar net of ik met vakantie ben. Holiday
Peter die niet boos is of zoiets, maar wel het nut van zijn posts even niet meer ziet
2098  Heart-Profit Boards / Heart-Profit ERP Support / Re: Keuringsrapport ook meertalig voor keuringsvoorschriften? on: June 24, 2008, 02:59:05 pm
Quote
Profit safetydata lijkt me wat een te zwaar middel om de microbiologische richtwaarden op een keuringsrapport te zetten.

Dat zij dan zo. smile
(lees : dan maar niet !)

Quote
Hooguit zou je moeten zeggen: stuur altijd de hele productspecficatie mee.

En ik zou niet weten waarom je dat niet altijd behoort te doen (en lees : waarom een klant dat niet zou (behoren te) willen.

Als ik even mag : als je nou naar onderstaand excerpt kijkt, draai je de boel dan niet om ? ik bedoel, weet je wel zeker dat een produkt specifikatie een produkt specifikatie is als feitelijk alle waarden domweg gevaarlijk kunnen worden in een ander "oogstjaar" ? ... en dat je dat oplost middels iets wat je Keuringsrapport noemt ? (voor wat betreft betreffende gegevens dan wel te verstaan).
Zie je ook voor je dat dit, zo gezegd, zo op de pot pindakaas komt te staan ?

Je bent dus hard op weg om van je Keuringsrapport een produkt specificatie te maken. Een produkt specifikatie die wat mij betreft per charge kan verschillen.

Als je echt van mening bent dat je het goed doet (is toegestaan hoor) dan moet jij ook geloven in die 66+ uur.
Je hebt van ons in elk geval nu voldoende duidelijk vernomen dat je je die 66 uur kunt besparen (desnoods door het in het Engels op te nemen).

Ik houd het er in elk geval op dat een module die je alle mogelijkheden biedt, waaronder alles per taal, inderdaad te zwaar is, anders zei je het niet. De verdere opties zijn bekend.

Ook hier kan ik niet veel anders meer doen dan zeggen : ik weet het ook niet meer. bye


2099  Heart-Profit Boards / Heart-Profit ERP Support / Re: produktie orders on: June 24, 2008, 10:10:27 am
Quote
Een manier om dit op te lossen is de Produktieorder te laten lopen via Produktieorderstatus "Z" (geen Prijs bekend).

Ik heb het idee dat niet veel mensen dit gaan begrijpen, wat overigens het gevolg is van de wijze waarop e.e.a. technisch in elkaar zit (lees gerust : moet zitten).

Wel zie ik dat Wouter op de e.o.a. manier als uitgangspunt neemt dat de order in stappen wordt opgeboekt, wat wat mij betreft hier niet aan de orde is. De "op e.o.a." zal dan ook het gevolg zijn van het gegeven dat erop wordt geanticipeerd dat de order in stappen wordt opgeboekt, wat op zich (en uiteraard) al aan de orde is bij het administratief verwerken. Dit is dan op zich weer het gevolg van het nooit kunnen afsluiten van een order waar in stappen gereedmelden inderdaad aan de orde is, èn waarbij een order ook als "gereed" mag worden gezien als er sprake is van een continu proces (je wilt dan altijd met de output aan de gang, ook al loopt de order nog een week door).
Probeer dit maar niet te doorgronden, maar accepteer s.v.p. dat er meer speelt dan je weet ...

Niet tegenstaande het voorgaande, blijft het zo dat het funktioneel gezien domme onzin lijkt dat de kostprijs wordt gerelateerd aan de ooit werwachte hoeveelheid output (de 30.000). (Dinand,) Denk ook maar eens aan het volgende, maar met wèl het uitgangspunt dat het juist zou zijn dat de kostprijs wordt gerelateerd aan de ooit verwachte hoeveelheid output :

Je maakt een Produktieorder administratief in het systeem. Dit doe je dus voordat de produktie daadwerkelijk begint. Wat doe je (wellicht, want ik weet het niet echt) ? je wilt 90.000 stenen maken en geeft dat ook in als verwachte Output. Het systeem genereert daarbij de consistente hoeveelheid grondstoffen. Mooi;
In jullie geval lijkt het me om te beginnen al zo te zijn dat je niet in staat bent om die hoeveelheid grondstoffen op de steen nauwkeurig af te wegen enzovoort. En anders *wil* je dat gewoon niet (te veel moeite, te veel tijd). Uiteraard hoort hier wel bij dat je er niet zo mee zit dat je wat te veel of te weinig stenen maakt, wat op zich mag inhouden dat je meer op voorraad produceert en minder of niet op klant. Immers, je lokt uit dat er meer of minder stenen uitkomen.
Goed. Hiernaast lijkt het me dan ook nog zo dat je bij een gegeven hoeveelheid grondstof óók nog eens niet kan afdwingen hoeveel stenen hier uit komen. Dit komt a. door de grondstof zelf (bijvoorbeeld vocht daarin zal uitmaken -> hoe meer vocht hoe zwaarder en voor de hoeveelheid output maakt het geen z*k uit) en b. doordat je ook nog eens uitval zult kunnen hebben.

Als je dit alles goed doorwerkt, dan kom je er volgens mij op dat waar je 90.000 als verwachte hoeveelheid output opgeeft, er bijvoorbeeld 91.000 kan uitkomen, je dit ook eeuwig op deze wijze noteert en ... er van je kostprijs maar weinig klopt. Immers, het systeem hanteert eeuwig en altijd die 90.000 en a. had jij nooit door dat die 1.000 te veel de kostprijs beïnvloedt omdat b. er te veel parameters zijn waarop je geen zicht hebt.

Mijn persoonlijke konklusie is dat er hier maar één goede basis is om het zo goed mogelijk te doen : het systeem MOET rekenen met de hoeveelheid Output zoals daadwerkelijk gebruikt en ZAL werken met de werkelijke hoeveelheid gebruikte grondstoffen (dit laatste is altijd al zo), en de enige parameter waarmee je dan kunt mis zitten is het vol*lme/gewicht van de grondstof die varieert op basis van vochtgehalte en die dus de kostprijs onterecht beïnvloedt. Merk wel op dat deze beïnvloeding net zo goed aanwezig is bij inkoop, en dat je er wel voor zult hebben gezorgd dat je hier tegenkunt. Ofwel, geen probleem (waar het wel degelijk de hoeveelheid Output blijft beïnvloeden !!).

Per saldo komt het er m.i. dan op neer dat je best de uitval mag weglaten in de Output en dat dat op zich keurig de Kostprijs beïnvloedt. Dus, de vochtperikelen daargelaten, gooi je er iets in wat volgens het volume/gewicht een bepaalde kostprijs heeft, en daar komt iets netto uit met aldus dezelfde kostprijs. Dit is ALTIJD juist (of ik moet iets vergeten).

Dinand, voordat je het bent vergeten, de moraal : het systeem rekent voor jou(w inrichting) steevast met de 90.000 en nooit met wat er werkelijk uitkomt (deze uitspraak is overigens gebaseerd op jouw schermkopieën plus wat Wouter ervan zegt). En dit moet FOUT zijn.

Om geheel andere reden dan jouw aangedragen probleem (althans, zoals ik het heb verwoord in mijn eerdere post) heeft Wouter gelijk in de aangedragen oplossing. Dat daarmee het probleem er ook niet zou zijn geweest is mooi meegenomen.
Probeer s.v.p. te doorgronden dat jouw situatie best bijzonder is, mits ze zo is zoals zojuist omschreven.
Is het laatste niet waar, dan werkt Wouter's oplossing nog steeds, maar zou het voor het gevoel mooier mogen. Dit "mooier mogen" zou dan wel heel merkwaardig maatwerk worden met een prijs die je liever niet betaalt. Denk ik.
2100  Heart-Profit Boards / Heart-Profit ERP Support / Re: Rubriek "Aansluitnummer bij groepsdebiteur" nodig? on: June 24, 2008, 09:37:09 am
Quote
Je mag nog wel even vertellen wat voor een "soort" fakturering je gebruikt c.q. op welke wijze je verzamelt àls je al verzamelt (denk ook aan Weekfakturering).

Het antwoord hierop komt in een volgende post neem ik aan ?
Pages: 1 ... 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 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 ... 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.096 seconds with 12 queries.