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

Login with username, password and session length
News:
 
   Home   Help Login Register  
Pages: [1]
  Print  
Author Topic: bij lodatv / lodawy uitbreiden met een rubriekje hoeveelheid  (Read 2699 times)
0 Members and 0 Guests are viewing this topic.
Johan
Designer
*****
Offline Offline

Posts: 2178


As it net kin sa't moat, dan mat it mar sa't kin.


View Profile
« on: December 08, 2009, 01:07:22 pm »

Wij zouden graag bij het toevoegen en wijzigen van prijs / kortingsafspraak LODATV / LODAWY (per klant /art/vrs/ periode van-tot) de mogelijkheid willen hebben om een hoeveelheid op te nemen. Deze hoeveelheid moet default in de voorraadeenheid van het artikel zijn. Ik weet even niet hoe snel je de voorraadeenheid van een artikel aan kunt / mag passen, maar mogelijk moeten we daarom de voorraadeenheid er ook maar bij opslaan.

We zitten te denken aan een veld waar maximaal 9.999.999 kan worden ingevuld. 7 karakters, 0 decimalen. We werken zo goed als uitsluitend met kilogrammen bij de eindartikelen.

Wat moet het kosten om dit vast te kunnen leggen?
Logged

KM
Wouter Rijnbende
Administrator
Partner
*****
Offline Offline

Posts: 5361


View Profile WWW
« Reply #1 on: December 08, 2009, 01:17:56 pm »

Wij zouden graag bij het toevoegen en wijzigen van prijs / kortingsafspraak LODATV / LODAWY (per klant /art/vrs/ periode van-tot) de mogelijkheid willen hebben om een hoeveelheid op te nemen.

Heb je al eens bij Prijsstaffels gekeken? LODSTV/LODSWY.

Bedoeld voor situaties als:

Vanaf 0,001 KG betaal je x,xx
Vanaf 1000 KG betaal je y,yy
Vanaf 10000 KG betaal je z,zz etc.


Ik weet even niet hoe snel je de voorraadeenheid van een artikel aan kunt / mag passen, maar mogelijk moeten we daarom de voorraadeenheid er ook maar bij opslaan.

De Voorraadeenheid van een Artikel aanpassen?
Waar heb je het over?
Een produkt wat altijd in "KG" door het leven is gegaan, kun je niet wijzigen in "en nu betekenen al die getallen ineens TN of L of ST".
Het is niet toegestaan de Voorraadeenheid te wijzigen ! Dat weet jij toch ook wel  Sad

Logged

Heart-Profit company ID : HA
Johan
Designer
*****
Offline Offline

Posts: 2178


As it net kin sa't moat, dan mat it mar sa't kin.


View Profile
« Reply #2 on: December 08, 2009, 01:45:41 pm »

Die staffels heb ik even over nagedacht, maar zijn voor mijn gevoel, corrigeer het maar als het niet terecht is, een korting per verkooporder, een soort 'ordergrootte'. M.a.w.: Besteld u 100 kilo in 1 keer, dan geldt prijs x,xx, besteld u op 1 order 1000 kilo dan eur y,yy besteld u op 1 order 10000 kilo dan eur zz,zz 

Het gaat mij er om:
De klant betaald voor artikel / vrs / van 1-1-2010 - 30-6-2010 xx,yy per kh (100 kilogram).

En nu zie ik ook mijn fout: het moet zijn "Verwachte hoeveelheid".

Met andere woorden. De prijs is gebasseerd op een verwachte afname van xxxxx kg

Ik heb wel gedacht om budgetten hiervoor in te zetten (lo 8-7-1)

Ik heb ook gedacht aan kontrakten, maar in mijn geval is de hoeveelheid is meer indicatief van aard. Bovendien werken kontrakten een stuk langzamer bij het toevoegen van een VO-regel.

Mijn probleem nu is: Er staan prijzen in het systeem, en op de achtergrond is er een verkoper die daar een hoeveelheid bij in gedachten heeft. Het is nu niet vastgelegd om welke hoeveelheden dit gaat. Het lijkt me wel zinvol dat we de afgesproken hoeveelheden derhalve vastleggen. Als dat ook kan bij staffel, hoe zou ik die staffel dan het beste in kunnen richten?

De voorraadeenheid is meer een overweging, van hoe zet je dat bij die verwachte hoeveelheid? Ik had idd niet de indruk dat de voorraadeenheid snel aan te passen was, maar het gaat mij er vooral om dat het duidelijk is welke eenheid geldt voor die "verwachte hoeveelheid".

Logged

KM
Wouter Rijnbende
Administrator
Partner
*****
Offline Offline

Posts: 5361


View Profile WWW
« Reply #3 on: December 09, 2009, 07:16:16 am »

Aan de ene kant zeg je dat de hoeveelheid slechts indikatief is, verderop schrijf je dat die hoeveelheid is afgesproken.

Als het is afgesproken, dan betreft het een kontrakt. De klant krijgt een prijs, op basis van de afspraak dat hij komende periode xxxxx Kg gaat afnemen. Haalt hij die hoeveelheid niet, dan heb je alle recht een faktuur na te sturen, omdat hij onterecht korting heeft gekregen.

Is er niets afgesproken, en bedenkt de verkoper hoeveel hij zou kunnen afzetten, dan is er formeel geen kontrakt met de klant. Indikatief wil je dit dan toch registreren. Wellicht is het bestaande veldje "prijsopmerking" dan al voldoende. Je beperkt je dan niet alleen tot invulling van een hoeveelheid, maar je kunt ook aangeven dat produkt X goedkoper is, omdat je Y duurder gemaakt hebt.
Logged

Heart-Profit company ID : HA
Johan
Designer
*****
Offline Offline

Posts: 2178


As it net kin sa't moat, dan mat it mar sa't kin.


View Profile
« Reply #4 on: December 09, 2009, 08:56:44 am »

Ik heb een indicatieve hoeveelheid afgesproken, in een enkel geval niet eens met de inkoper (van de klant) expliciet besproken.

Kontrakten willen ze hier niet aan beginnen, met name omdat veel te langzaam werkt bij het invoeren van een order. Let wel, er zijn klanten die meerdere verkooporders per week doen, het is beslist niet zo dat de kontrakthoeveelheid er in 1 week door heen gaat. Die kontrakthoeveelheid wordt uitgesmeerd over tientallen verkooporders en dus ook meerdere maanden.

Een opmerking is inderdaad mooi om een prijsopmerking te pennen waarom X duurder of goedkoper is dan Y, maar is te vrijblijvend, je moet er maar net even aan denken om daar de hoeveelheid bij te noemen. En dan wordt het iets van "opmerking: 1500 tn". en bij een volgende "50000 kg".

Door een extra rubriek "Indicatieve hoeveelheid" op te nemen, kun je daar niet over heen lezen, je leest m niet over het hoofd. Misschien moet je daarom na het bevestigen van blad 2 van lodatv wel automatisch een budget kunnen toevoegen, waarbij dan standaard desbetreffende relatie, artikel ( en evt verschijning) + periode worden overgenomen. Mijn vraag komt het dichtste in de buurt van de werking van de budgetten. Ik heb namelijk geen enkel recht om aanvullende "schade"facturen te sturen over niet afgenomen hoeveelheden.
Logged

KM
Johan
Designer
*****
Offline Offline

Posts: 2178


As it net kin sa't moat, dan mat it mar sa't kin.


View Profile
« Reply #5 on: December 21, 2009, 03:43:49 pm »

Door een extra rubriek "Indicatieve hoeveelheid" op te nemen, kun je daar niet over heen lezen, je leest m niet over het hoofd. Misschien moet je daarom na het bevestigen van blad 2 van lodatv wel automatisch een budget kunnen toevoegen, waarbij dan standaard desbetreffende relatie, artikel ( en evt verschijning) + periode worden overgenomen. Mijn vraag komt het dichtste in de buurt van de werking van de budgetten. Ik heb namelijk geen enkel recht om aanvullende "schade"facturen te sturen over niet afgenomen hoeveelheden.


Als een inidicatieve hoeveelheid bij een prijsafspraak dan niet zo fraai is, kan het automatisch toevoegen van een budget dan wel tot de mogelijkheden behoren? Ik weet, er gebeurd veel meer nadat je blad 2 LODATV met <F1> hebt bevestigd.  (denkend aan VO-regels bijwerken en tig controle's) . Als nou LOBUTV2 Met niveau F/C/W (of CFW zoals profit dat zelf dan overruled) tevoorschijn komt, bij voorkeur met de "Bekende" velden alvast ingevuld, dan zouden we er volgens mij ook al zijn. 

Bewust niet LOBUKZ, maar direct lobutv2 met genoemde niveau's.
Logged

KM
Wouter Rijnbende
Administrator
Partner
*****
Offline Offline

Posts: 5361


View Profile WWW
« Reply #6 on: December 21, 2009, 04:16:55 pm »

E.e.a. maar even per mail afhandelen. Heb je er zojuist een gestuurd.
Logged

Heart-Profit company ID : HA
Wouter Rijnbende
Administrator
Partner
*****
Offline Offline

Posts: 5361


View Profile WWW
« Reply #7 on: December 22, 2009, 12:32:43 pm »

Punt bij deze afgehandeld; besloten om verder maar even niets te doen.
Logged

Heart-Profit company ID : HA
Pages: [1]
  Print  
 
Jump to:  

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.14 seconds with 20 queries.