Zou inderdaad handig zijn om dit direct mee te melden
Ik weet dat onder DOS dit vaak wel opgevraagd kon worden, maar een directe melding met usercode in het scherm zou inderdaad duidelijker zijn

Het lijkt me eerder dat jij een foute implementatie hebt mbt mengrecepturen en dynamische recepturen

Immers bij mengrecepturen is zover ik kan zien mijn situatie altijd "goed" en in alle andere gevallen praat je niet over mengrecepturen

Zie jouw eigen helptekst:

I.g.v. een Mengreceptuur kan het eindprodukt pas worden gereedgemeld           
indien de Grondstoffen werden afgeboekt, immers halverwege tijdens   
het Produktieproces zal nog geen eindprodukt klaar zijn. Ook hier     
blijkt weer dat het totaal aantal eenheden grondstof gerelateerd is   
aan het totaal aantal eenheden eindprodukt.                           

Blijft mijn stelling dus overeind...

Heren van Heart, waarom past deze functie die datum aan?

-----------------------------------------------------------------------------------
Marco,
Wanneer ik een inkoopfactuur probeer te boeken en door het beginscherm heenloop, past de vervaldatum zich automatisch aan aan de datum die je invoert bij de factuurdatum. F1 niet gebruikt. Wijzig je echter de factuurdatum dan blijft de vervaldatum staan. Hoe kan dit en is dat wel okay zo?
Pad: ADFITV


Met vriendelijke groet,
Bas Dekkers
-----------------------------------------------------------------------------------

Dat is mooi,
Zat er een beveiliging in het systeem tegen "domme fouten" (mijn optiek)
Zetten jullie dat voor een andere klant uit, en mag ik € 450 euri betalen om de oude situatie weer af te kunnen roepen!

En daarbij het argument, je merkt het pas na een half jaar:
Deze functionaliteit beveiligd tegen "stomme" fouten waarvan ik hoop dat ze nooit voorkomen, maar waarvan we beiden wisten dat ze wel mogelijk zijn (gezien de ingebouwde functionaliteit).

Daarnaast weet ik dat ik normaliter redelijk consequent de releasenotes lees en ik kan me deze melding en de impact niet herrinneren: zal wel weer in de releasenotes hebben gestaan als korte melding in de trand van : "Controle aangepast"

In de releasenotes vind ik in ieder geval niets over een melding productiewinst/productieverlies
Alleen over uitval bij assemblage recepturen, en wij gebruiken mengrecepturen

Klopt als een bus.

Het probleem is dat we inderdaad weinig "dynamische" eenmalige klanten hebben.

En bij de meeste b-2-b klanten voor grote multinationals hebben wij bv de info vrachtbrief hard nodig.
Immers als wij voor bedrijf X wat moeten leveren aan Shel Pernis of DSM op chemelot maakt het voor de levereing erg veel uit of je bij poort 2 of poort 30 staat met jouw vrachtwagen. Vaak communiceren die "plants" totaal nioet met elkaar en zal niemand aan kunnen geven dat het materiaal naar poort 30 moet.

Dat verklaart mogelijk waarom jij aangeeft dat je niet had verwacht dat wij zoveel afleveradressen hebben, maar je moet je realiseren dat bij grote organisaties het adres : "Shell Pernis" net zo duidelijk is als "die meneer met bril in Barneveld"

Vandaar dus het fenomeen dat wij inderdaad tegen de grenzen van het huidige systeem aan gaan lopen.
Wat betreft jouw opmerking mbt de dynamische adressen: De klant waar wij het grootste probleem mee hebben is gelukkig wel zo'n "dynamische" klant, dus ik zal een printje van deze tread aan onze verkoopafdeling sturen zodat de weten hoe om te gaan met adres 999

thx

Zoals reeds telefonisch aangegeven ben ik daar niet blij mee.

We hebben juist voor een ERP systeem gekozen om dit soort zaken niet mogelijk te maken.
Als dat nu gewijzigd is naar een "softe" melding, betekent dit dus dat we nooit een sluitende voorraadsituatie krijgen.

Daar wordt ik dus echt niet blij van...

Je kiest in mijn opinie juist voor een ERP systeem om zaken dicht te spijkeren, niet om er allemaal workarounds in te bakken.
Het neerleggen bij een willekeurige gebruiker betekent altijd ellende, zoals dit ook weer laat zien.
Kijkk alleen maar naar kostprijzen e.d.

Hoezo, "het is niet bedoeld voor wat jij ermee doet":

Volgens mij gebruiken we deze zaken allemaal legitiem, zoals het ook in jouw helpteksten omschreven staat...


aantal dagen transport
Door het invullen van deze Rubriek kunt u opgeven hoeveel dagen het   
Transport duurt. Het is echter niet mogelijk om dag delen in te       
vullen.                                                               

Wordt er nu een Verkooporder aangemaakt en de Rubriek                 
"Leverwk/-datum/-tijd" wordt niet overschreven, kan door invullen van
de Rubriek "Datum in Huis" a.d.h.v. de Kalender Openingstijden en de 
alhier ingevulde Transporttijd, de Leverdatum opnieuw worden bepaald.

Standaard wordt 0 dagen gehanteerd.                                             

Info vrachtbrief
De tekst die U bij deze Rubriek invult zal worden gebruikt als       
default tekst voor een tekstregel, welke zal worden afgedrukt         
op een Vrachtbrief voor de betreffende Kliënt.                       

Toeslagen
Omdat de Toeslag Handlingkosten niet voor alle Artikelen geldt en     
niet voor alle Klanten geldt, en het per Klant niet voor alle         
Afleveradressen geldt, zal bij zowel Artikel, Klant en de bijbeho-   
rende Afleveradressen moeten worden aangegeven in welke gevallen de   
Toeslag Handlingkosten van toepassing zijn.                           

ABC transactie
Geen specifieke helptekst, maar wel koppeling naar BTW berekeningen

Opdracht tot export
Geen specifieke helptekst, maar wel koppeling naar BTW berekeningen

Verkoper
Geen specifieke helptekst, maar wel koppeling naar Management info, DKK's en commissie berekeningen

Verkoopgebied
Idem als verkoper

of de oude welombekende <CTRL><Q>
om dan toch maar inde tijd terug te gaan

LOL,

toch hebben we ze wel.
Wij versturen n.l. ook in naam van onze opdrachtgevers en daarvan hebben er heus wel een paar wel meer dan 999 klanten, oftewel meer dan 999 afleveradressen.

met vriendelijke groet namens
Distributiecentrum ADJE CHEMIE

Als ik de helptekst lees kom ik toch tot de conlusie dat mijn interpretatie: n.l. het aantal ingestoken kg grondstoffen en opgeboekte product mag niet meer dan X % afwijken, klopt.

Zo is deze parameter ook aan ons uitgelegd en ik weet dat ik in het verleden meerdere malen de melding kreeg: "Er wordt een niet reeele productiewinst gegenereerd" waarop het systeem weigerde...


Zie onderstaande helptekst:



Bij Meng-Recepturen mag het uitgangspunt zijn dat (bijv.) het gewicht
van alle grondstoffen het gewicht van het eindprodukt oplevert.       
Echter, juist bij deze Meng-Recepturen ontstaat meer of minder       
Produktie-verlies, waardoor minder gewicht eindprodukt ontstaat       
dan verwacht;                                                         

Middels deze Parameter kan worden aangegeven hoeveel Produktieverlies
is toegestaan, wil het systeem het Gereedmelden van de Produktieorder
nog accepteren.  Bedenk hierbij dat het Gereedmelden op zich normatief
zou kunnen plaatsvinden (dus boeken wat het systeem verwacht op basis
van de Receptuur), doch dat dit in de praktijk niet zal gebeuren,     
aangezien e.e.a. staat of valt met juiste voorraad-registratie. Aldus
zal bij het Gereedmelden (Opboeken Gereed Produkt) "automatisch" de   
daadwerkelijk opgeboekte hoeveelheid worden geregistreerd, omdat     
anders het voorraadverschil eindprodukt (veelal beheerd door een     
andere afdeling : expeditie !!) niet zal kunnen worden verantwoord.   

Dus, juist omdat de daadwerkelijke hoeveelheid gereed produkt zal     
worden opgeboekt, terwijl de grondstoffen veelal wèl normatief werden
afgeboekt (Produktie doet binnen haar afdeling wat ze wil, en is zelf
verantwoordelijk voor door haar gekreëerd voorraadverschil) zal een   
onevenredig verlies kunnen "ontstaan".  Immers, als er minder         
grondstof werd verbruikt dan geboekt (werd normatief gedaan),         
komt er wel degelijk minder eindprodukt uit de order; de Gereed-     
melding wordt zoals vooromschreven wèl naar werkelijkheid gedaan,     
waardoor automatisch een niet-reëel Produktieverlies is ontstaan.     

Deze Parameter geeft aan hoeveel in percentage deze afwijking mag     
zijn. Dus, stel dat 10 % wordt ingevuld, dan zal bij 100 kg           
grondstoffen 90 kg gereed produkt mogen ontstaan, minder niet.         

Voor de goede orde wordt nog opgemerkt dat de 10 kg verlies uit het   
voorgaande, daadwerkelijk verlies kan/mag zijn, doch dat hier ook     
"10 kg speling" kan worden gehanteerd voor "het nog normatief mogen   
afboeken".  Met andere woorden, Produktie is niet geïnteresseerd in   
de laatste 10 % detail, "wenst" dus 10 % Voorraadverschil, doch       
verliest geen enkele tijd aan het juist moeten registreren van       
afgeboekte grondstoffen (normatief afboeken kan met één druk op       
de knop).                                      

Ik zou toch liever een simpelere registratie hebben.

Immers nu boek je 2 maal de factuur, dus ook de BTW in een bepaalde BV, als blijkt dat de factuur voor een andere BV is (iets wat hier vaak voorkomt met veel BV's op 1 terrein en een leverancier die aan meedere van die BV's levert) loop je sowiso al mis met de BTW registratie.

Buiten dat betekent het dat iedere factuur formaal 2 maal langs de financiele admin moet, en dat is dubbel werk.
Ik zoek eigenlijk meer iets wat lijkt op de bezoekersregistratie, waarvanuit een factuur dan "gepromoveert wordt naar de "echte" factuurregistratie.

Als ik werk volgens jouw optiek creer ik ee gigantisch bedrag op een tussenrekening aan openstaande facturen in een willekeurige periode, welke de financiele rapportages verminkt, totdat de zaken in de goede groep geoekt worden.

Het is-se simpel:

Maak een printer aan in windows op jouw PC.
Zet de instellingen zo dat als je vanuit bv kladblok print, deze netjes niet (middels de printinstellingen onde printer eigenschappen)
Noem deze printer dan Nas-niet of zo om hem duidelijk te identificeren

Als dat werkt: Probeer het dan eens met die driver win-pdf
In principe stuurt deze n.l. alleen lettertype aan.

Dat werkt zo goed met onze Panasonic (na enkele uurtjes spelen weliswaar) om geniete A3 velle te krijgen van de behoeftelijsten. en ook met pdf995 en Cutepdf om bv analysecertificaten te genereren in pdf tbv van mail maar klant

MK

Hoe zit dat dan met track en trace en management overzichten?
Volgens mij kunnen die (nog) niet overweg met deze functionaliteit

Hoe kan ik dus traceren dat een afleveradres gebruikt wordt?

Ook mis ik duidelijk logistieke functionaliteit, zoals:
 - aantal dagen transport *
 - Verkoper                    **
 - Verkoopgebied             **
 - Info vrachtbrief (afleverinstructies) *
 - Koppeling toeslagen      *
 - ABC en opdracht tot export   *

*  wordt gebruikt logistiek
** wordt gebruikt in management info

om maar alleen de door ons veel gebruikte velden te noemen.

Ik ben blij dat jullie iets hebben verzonnen, maar ik lever wel veel functionaliteit in
Had liever gehoord dat jullie de aflevradressen op konden krikken naar 9999 items....

lijkt in het probleem van subcharges zijn oorsprong te vionden staat

http://ha1.heartprofit.nl/profit/index.php?topic=18295.0

pikt iemand dit nog op?
Is toch wel essentieel dat dit goed gaat

Anders kun je heel wat materiaal uit lucht genereren, lijkt me handig....