Heart-Profit ERP
July 01, 2024, 08:57:13 pm *
Welcome, Guest. Please login or register.

Login with username, password and session length
News:
 
  Home Help Login Register  
  Show Posts
Pages: 1 ... 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 [87] 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 ... 273
1291  Heart-Profit Boards / Heart-Profit ERP Support / Re: Controle fakturen voordat deze gemaild worden on: July 22, 2010, 10:51:27 am
Tja ...
1292  Heart-Profit Boards / Heart-Profit ERP Support / Re: Controle fakturen voordat deze gemaild worden on: July 22, 2010, 06:33:29 am
Nee, dat is helemaal geen onzin, maar wat nu als er iemand komt die hetzelfde wil maar geen Outpook heeft, maar gewoon Outlook Express. Dan kunnen wij opnieuw beginnen.

Je kan natuurlijk denken dat we dan ook opnieuw eraan verdienen, maar de tijd dat ik zo denk (wil denken) moet nog steeds komen ...

Ik zie liever dat Outlook Express zo kan worden getweaked dat het daar ook werkt. En dat lijkt me toch wel mogelijk ... of ?

Wouter ?
1293  Heart-Profit Boards / Heart-Profit ERP Support / Re: Controle fakturen voordat deze gemaild worden on: July 20, 2010, 06:00:38 pm
Nou, Wouter zal wel heel blij zijn dat jij zijn idee een goed idee vindt, maar ik vind het helemaal geen goed idee.
Hoe kan je nou met een oplossing komen waar de helft nooit iets aan zal hebben ?? Anders gezegd, hoe ga je die andere helft dan bedienen ?

Terug naar de tekentafel.
Later ...

Sorry Pascal.
1294  Heart-Profit Boards / Heart-Profit ERP Support / Re: Prijsbepaling inkoop charge gaat niet goed bij af en bij boeken on: July 20, 2010, 05:55:46 pm
Quote
V.w.b. de prijsbepaling in een handmatige Voorraadmutatie kunnen we dat in theorie ook doen; waarbij het zoeken in de Voorraadmutaties dan afhankelijk moet zijn van of het een Koop- of een Produktieartikel betreft.

Zullen we eerst eens even helemaal niets doen voordat jullie de boel zo door elkaar halen dat niemand meer weet waar het over gaat ...

Marco, leuk dat je nadenkt.
Kan je nog even aangeven wat er fout is aan de Kostprijs ... ik wil het nog wel een beetje kunnen volgen.
1295  Heart-Profit Boards / Heart-Profit ERP Support / Re: Prijsbepaling inkoop charge gaat niet goed bij af en bij boeken on: July 19, 2010, 07:59:52 pm
Tabel LOCP.
1296  Heart-Profit Boards / Heart-Profit ERP Support / Re: Prijsbepaling inkoop charge gaat niet goed bij af en bij boeken on: July 19, 2010, 03:40:53 pm
Quote
De prijsverhoging komt uit een kostprijsverhogende DKK op de inkooporder regel en is dus formeel niet "gefreubelt". Maar dit is een legitieme implementatie binnen het pakket.

Hier heb je gelijk in !

Maar dan heb ik het gevoel dat je misschien toch ergens iets doet waardoor dit om zeep gaat. Niet zeker natuurlijk, want er kan best ergens een fout in zitten. Daarom :

Heb je een voorbeeld voor ons van een produkt wat je inkoopt + DKK, wat vervolgens een onjuiste Charge waarde zou hebben ?
Het liefst in de Testbestanden, maar anders komen we er ook wel uit.
1297  Heart-Profit Boards / Heart-Profit ERP Support / Re: Bijhouden laatste wijziging verkooporder, gelijk aan werkwijze recepturen on: July 19, 2010, 12:51:03 pm
De enige goede methode die alles 100% zal dekken (en mat "alles" bedoel ik dan meteen alle tabellen smile) zal zijn gebaseerd op de Transakties. Dus, als je Order twee keer wordt gewijzigd zal iedere normale methode (die niet meteen al meer kost als een algemene methode) alleen de laatste wijziging (en wie etc.) kunnen laten zien.

De methode gebaseerd op de Transakties zit al eeuwen in ons hoofd, maar nooit heeft dit geleid tot iemand die het daadwerkelijk wil, en er ook iets voor wil betalen. Maar houd het erop dat je op statistiek-achtige wijze zal kunnen zien wie wat wanneer heeft gedaan tot op veld- en waarde niveau. Stel dat dit je wel aanstaat (nogmaals het werkt dan voor alle tabellen) en dat we dat voor een module(Basis)prijs ad 400 o.i.d. zouden kunnen maken, dan kan je daarna voor je zien dat er uitbreidingen op komen zoals het kunnen selekteren op Waarde. En, weer denkend aan de normale Standaard Overzichten en hoe die werken, dan zal je wel alle waarden "groen" in tabel XYZ kunnen selekteren, maar ook in alle tabellen. Of in kombinatie met User-id ABC.

De gegevens zijn allemaal voorhanden, er zijn alleen nooit rapportages voor gemaakt.

N.b.: Zoiets heette vroeger een Audit-Trail. Misschien nu nog wel.
1298  Heart-Profit Boards / Heart-Profit ERP Support / Re: Prijsbepaling inkoop charge gaat niet goed bij af en bij boeken on: July 19, 2010, 12:37:35 pm
Ter overweging (meer voor Wouter dan voor Marco) :

Ik denk niet dat dit kan, dan wel dat we moeten proberen dit na te streven (omdat het eigenlijk niet kan smile). Immers :

Niets zegt dat je hier een Charge officieel duurder hebt gemaakt. Je freubelt handmatig een ietwat met de originele charge (verandert de prijs, voegt een DKK toe, enz.), maar er ligt niets aan te grondslag. Financieel technisch lijkt me dit al niet te mogen omdat je het niet kan aantonen (ja, een *impliciete* Kostrpijsverandering, maar daar trappen de heren niet in). Een voorbeeld (voor je eigen gedachten hoe dit wel moet en mag) :

Als je transporteert, en daar DKKs aanhangt (Transportkosten, desnoods inklaring, etc.), dan heb je een dokument wat formeel aantoont waarom de Kostprijs hoger is geworden. Dàn werkt het dus wel (want de Charge (!!) krijgt de Kostrpijs, niet het Voorraad-Item ... ja ook, maar afgeleid van de Charge in dit geval).

Als je handmatig de Kostprijs aanpast (wil aanpassen) dan is de enige methode die legitiem is, werken volgens VPP en de hele handel opnieuw doorrekenen. Nee nee, dat werkt niet voor jou (Marco), maar het is wel een legitieme methode.

Je zal m.i. dus op zoek moeten naar die legitieme methode, die de *Charge* zijn andere Kostprijs geeft. In jouw geval zou dat een bewerking moeten zijn, en dus minimaal een Omvorm Opdracht (en anders een Produktieopdracht).
Zonder zo'n opdracht maar het Chargenummer veranderen, en daar voor het eerst de hogere Kostprijs aan toekennen zal ook werken, lijkt me.

Edit : Wouter's en mijn post hebben elkaar aardig gekruist, en ook al zijn de verhalen volledig verschillend, de moraal is dat wat je (Marco) doet, niet kan. Niet "zo maar", en altijd op te lossen aan jouw kant (procedureel dus).
1299  Heart-Profit Boards / Heart-Profit ERP Support / Re: Controle fakturen voordat deze gemaild worden on: July 16, 2010, 01:31:34 pm
Alleen fakturatie.

Alhoewel ik me kan voorstellen dat het op meer te kontroleren dokumenten van toepassing kan zijn. Maar pas op, dat vergt ook meer aanpassingen (meer dan de fakturatie, die er al half voor is gemaakt (zoals je hebt gezien smile)).
1300  Heart-Profit Boards / Heart-Profit ERP Support / Re: Controle fakturen voordat deze gemaild worden on: July 16, 2010, 12:08:25 pm
Quote
1. Menu 3-3-3 Genereren fakturen, Printen op J maar dan naar scherm. Alle fakturen worden per stuk naar het scherm geprint (dit gaat prima).

Als XP ong. 2,5 taakbalk vol met taken heeft, geeft XP het op ...

Hoeveel fakturen heb je per dag, 3 ?
Dit is een "eindige" oplossing.
1301  Heart-Profit Boards / Heart-Profit ERP Support / Re: Controle fakturen voordat deze gemaild worden on: July 15, 2010, 04:44:24 pm
Leuk hoor, ga maar weer uit van de bestaande gemaakte coding. smile Maar toch wel goed ...

Er is nog iets anders ... (en nu zal het wel neerkomen op jouw eerder genoemde oplossing) ...

Zoals we ooit zijn begonnen met het emailen / faktureren, moest dit overeenkomen met de wijze waarop EDI werkt. En, dit werkt 100% zeker (tenzij het intussen is veranderd) op precies de wijze die jij beschrijft. Dus, je kan EDI verwerken als EDI aan de orde is, printen als EDI niet aan de orde is, maar beiden doen als je een papiertje wilt bewaren en dat is bedoeld voor de testfase van EDI waarbij je OOK de papieren faktuur stuurt. Met een beetje geluk vind je dat ergens in de helptekst.

Nou is het grappige (helemaal niet) dat ik me dat van die extra loop herinner (helaas van niet zo lang geleden als jij zegt, maar dat zal aan mij kunnen liggen), terwijl ik even niet zie hoe EDI dat dan doet. Maar kennelijk niet met een extra loop, want EDI in deze bestaat al 13-15 jaar. Ik maak me er dan ook sterk voor dat die extra loop ergens anders voor was, al was het maar omdat deze niet in juli 2009 is ontstaan. Nou ja, ik zie gewoon niet voor me dat dat zo lang is geleden (maar je zal het wel in de coding hebben gezien).
En zo simpel is het ook allemaal niet, want volgens mij hebben we ook nog (extra) loops voor het genereren van HTML, of weet ik veel.

Feit is en blijft dat je nu niet kan doen wat ik wel wil(de !), en dat het wat dat betreft dus altijd fout is. Maar feit is net zo goed dat als je het oplost zoals jij voorstelt (zie eerdere post), je altijd alles kan doen wat nodig is. Maar let wel op :

Waar ik jou geen rekening mee zie houden is :

a. Zo'n soort keuze aan de Debiteuren kant (zie EDI);
b. De expliciet te ondervangen kombinatie met het faktureren (en dat geldt NIET bij EDI !);
c. En met name het anticiperen op "als je eerst de ene doet, blijft er vanzelf voor de andere niets over".

Ad c.
Had ik daarstraks al willen zeggen maar vergat ik;
Wat ik mij herinner toen het is bedacht, is dat je er vanuit mag gaan dat als je eerst "het ene" doet, er vanzelf voor "het andere" niets anders overblijft dan juist dat andere. Zonder het nu verder uit te werken houdt dit in dat de ondersteuning van 1 van de 2 voldoende it, mits je maar in de juiste volgorde opereert. Echter, dit gaat niet meer op bij een soort "door elkaar geknoei" van zaken kontroleren, even eentje opnieuw doen, enzovoort. Wat echter blijft (want dat staat voor mij vast) is dat je tevoren moet kunnen kontroleren voordat je de boel de deur uit mailt. En DIT is nou net weer nooit aan de orde geweest bij EDI. Leuk heh ...


Ad a.
Weet ik niet zeker. Als je e.e.a. aldaar ondersteunt, zou je gaan zeggen "en deze Debiteur wil ik eerst altijd kontroleren voordat 'ie de deur uitgaat". Wel, als je het kromme hiervan doorhebt, moet je nog maar eens de overeenkomst met EDI zien te vinden, terwijl het nu wel hetzelfde werkt als EDI. Kan nooit.



PS: Het is niet helemaal voor niets dat ik daarstraks 4 keer overnieuw moest beginnen. Het is gewoon een K-ding.
1302  Heart-Profit Boards / Heart-Profit ERP Support / Re: Controle fakturen voordat deze gemaild worden on: July 15, 2010, 02:07:37 pm
Haha, Wouter, sorry maar volgens mij bekijk je het verkeerd (intussen schrijf ik nu voor de 4e keer iets anders hier, dus verwarrend is het op z'n minst). Poging 4:

Het doen van Beiden is zinloos. Immers, waarom een kopie bewaren van een email, als je niet ook een kopie van de print bewaart (want, die stuur je de deur uit). Dus, Beiden moet betekenen : Emailen waar het kan.
N betekent : Nooit emailen (dus alleen printen, en wel alles).
J betekent : alleen emailen (en niets printen).

Ik denk dat je al nooit een andere funktie (Orderbevestigingen) erbij moet slepen, omdat dat funktioneel al heel anders in elkaar zit (lees ook : als je één van de opties niet hebt, houdt het nog niet in dat de overigen hetzelfde moeten werken).
Maar verder heb ik toch zelf bedacht hoe dit moet werken, en wat vooral inklusief de kontrole op voorhand was. Het is alleen niet zo gemaakt. Beschrijven hoe het gemaakt is is wel nuttig om te weten, maar zinloos als bewijs hoe het moet werken. Ok ?

Nog één ding (want daar is de fout w.s. ontstaan) :

Quote
Bij B = Beide zal een Faktuur die gemaild wordt óók geprint worden; bedoeld om nog een tastbaar "bewijs" te hebben voor in de dossiermap, voor die fakturen die gemaild zijn.

Deze zin zou je ongeveer letterlijk in de helptekst voor het automatisch aanmaken van de Kontakten kunnen terugvinden, immers, daar geldt dit wel degelijk (wel onder het mom "hoe je het met je prints doet en deed zoek je maar uit"), en dat is ook letterlijk zo bedacht (en werkt nu ook zo ... maar éérst niet !). En omdat alles in dezelfde periode is gemaakt, zal het daar zijn misgegaan. Als je achteraf bekijkt hoe dat met die Kontakten werkte in de eerste versie, blijken beiden kwa principe (toen) omgedraaid gemaakt te zijn.
Geeft niets, als we er nu maar niet teveel woorden meer aan vuilmaken.
1303  Heart-Profit Boards / Heart-Profit ERP Support / Re: Controle fakturen voordat deze gemaild worden on: July 15, 2010, 01:07:23 pm
Quote
Buiten dat, fakturen eruit vissen van klanten die gemaild moeten worden lijkt me lastig en geen fijne oplossing.

Helemaal mee eens. Maar nagedacht over mijn voorstel in deze heb je (zo te zien) ook niet. no
Zie ook hieronder.

Quote
Is er niet iets te bedenken dat je toch meerdere fakturen op het scherm kunt afdrukken? Je hoeft alleen maar de fakturen die gemaild worden, op het scherm te controleren.

Ik snap heus dat het een goed idee is om bomen te besparen, maar vergeet niet dat waar jullie die wegen aanleggen de bomen er toch uitmoeten. Jaja heheh, leuk. nea

Als je je nu eerst serieus afvraagt of dit wel werkbaar is, moet dat wel kunnen worden gemaakt;
Als je je dat niet serieus afvraagt kan het nog steeds worden gemaakt, maar geef je het geld wellicht voor niets uit yes.

Zo, na al deze onwijs interessante mededelingen helpt het wellicht als ik zeg dat ik het niet zou zien zitten om zo'n kontrole op het scherm te doen. Ik bedoel, volgens mij werkt dat zo gewoon niet. Niet zonder meer. Kijk :

Je draait je Faktuurrun, en omdat iedereen op een gegeven moment leuk meedoet met die email verhandelingen krijg jij 69 fakturen op je scherm. N.b.: Vooralsnog zie ik het zo dat die in 1 dokument komen, omdat dat redelijk oneindig is. Ik bedoel, als er 69 taken opgestart zijn zie niet alleen jij, maar ook de PC door de bomen het bos niet meer (en bomen kappen wil je niet). Dus, 1 lang dokument in ? zal wel Notepad zijn. Je bent na 3 keer PageDown op de helft van de tweede faktuur en denkt "drommels, volgens mij zijn de DKKs onjuist". Mooi; Na een kleine alt-tab zit je weer in Profit en gaat op onderzoek. Let wel, JIJ. Hoe zou het immers anders kunnen ?
Drie kwartier verder, en na de fout gevonden te hebben, ben je er eindelijk aan toe om weer eens PageDown in je NotePad te doen. Sh*t, weer fout. Zelfde probleem misschien ? na 5 minuten, inderdaad, hetzelfde probleem. Hierna kan je waarempel met 8 keer Pagedown 4 fakturen goedkeuren, maar vindt vervolgens weer een probleem. Het is niet helemaal duidelijk, en na 20 keer alt-tab moet je het even opgeven. Dan maar de volgende. Het zit je weer mee, want er zijn nu maar liefst 9 fakturen achter elkaar goed.
Heheh, na een uurtje ben je er toch doorheen, en bent nu toe aan de nieuwe faktuurrun die alles goed zou moeten ophoesten.
Ehh, hoe ? wat ? Tja niet helemaal handig, want je weet niet meer welke je opnieuw moet bekijken. O nee - welke je opnieuw moet *maken*. Ok, volgende keer maar ergens een kruisje in de NotePad zetten, opdat je kan zien welke je opnieuw moet draaien.
Jaja, dat werkt inderdaad al een stuk beter. Alleen word je helemaal debiel van dat alt-tab gedoe om die reeks van 1 op te geven. Hmm ... kopiëren plakken misschien. Jaja, dat helpt alweer.

Wel, uiteindelijk ben je eruit (de te volgen procdure), maar je komt er toch duidelijk achter dat je alles alleen moet doen, en het wel 3 keer zo lang duurt als voorheen. Maar dat vindt niemand erg, mits er maar een boom mee wordt bespaard, en dat doe je zeker. Helaas wordt er echt niemand extra voor aangenomen, maar dat geeft niet echt, want jij werkt graag over. Elke dag van 17:00 tot 19:00. Niets aan de hand.


Wel, ik heb mijn best weer gedaan, en ook al zal alles enorm overdreven overkomen, half gelijk zal ik best wel hebben.
Voor het geld dat het kost hoef je het niet te laten, want ik meen dat jullie niet vaak contant betalen, dus daar zal geen boom van omvallen. Ik vermoed wel dat een stom euveltje als het achter elkaar afdrukken van de fakturen naar het scherm je zo op ergens tussen de 8 en 16 uur komt te staan omdat het redelijk diep ingrijpt op de printer drivers. Het kan denk ik wel zonder Bedrijfsparameter (want niemand zal het erg vinden dat het zo werkt), maar toch. Het verhaal zal wel beginnen bij het Faktureren en iets van een J/N/B/S of zo, waarbij de S emailers impliceert die je naar het scherm wil hebben.

Goed. Denk goed na over de procedure, en dat je bijvoorbeeld na een keer teveel op Esc drukken met je Notepad, alles kwijt bent. Dat ding op voorhand (en daarna regelmatig) saven na je kruisjes enz. is al iets wat daarbij kan helpen.

Dit kostte alvast een half uur. smile
1304  Heart-Profit Boards / Heart-Profit ERP Support / Re: Controle fakturen voordat deze gemaild worden on: July 15, 2010, 12:33:40 pm
Quote
Wanneer ik Emailen Kontaktpers. J/N/B op J zet, worden de fakturen die gemaild moeten worden gemaild, maar de rest ook geprint. Alleen mailen lukt niet.

Dit lijkt me niet juist, en moet sowieso worden opgelost. Dit scheelt weer een boompje.
1305  Heart-Profit Boards / Heart-Profit ERP Support / Re: Verzoek aanpassing berekening kostprijs menu 1.5.1 on: July 14, 2010, 08:41:10 pm
Ik ben het nog niet vergeten hoor.
Pages: 1 ... 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 [87] 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 ... 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.238 seconds with 12 queries.