Staat inmiddels bij je op het systeem.

Default waarde is omgedraaid.

Bij het Genereren/Printen van de Faktuur moeten er een aantal Printer koppelingen aanwezig zijn voor het Printen van de Faktuur en het Printen van de acceptgiro. Nu er default voor gekozen is, om ook een Faktuur te mailen moet er ook een koppeling daarvoor aanwezig zijn. Dus koppel IEOPRUFF aan Printer Scherm en Driver HTM en e.e.a. kan weer gewoon gebruikt worden.

Misschien was/is het inderdaad wel niet zo handig om de default waarde op "J" te hebben staan, wellicht moeten we dat veranderen naar "N". Even afwachten of het eenmalig aanmaken van een dergelijke koppeling veel hinder oplevert. Of moeten we maar gewoon default 'N' opnemen?

gereed en staat bij je op het systeem.

Upgrade staat er.

Hallo PWoelders,

E.e.a. is gereed zie http://ha1.heartprofit.nl/profit/index.php?topic=21767.0. Hievoor heb je echter wel een Upgrade nodig.

Deze haalt hij uit een berekening. Zie onderstaand kopie van de Help-tekst bij Funktie Hmenu-1-1-1-8-9-4 Raadplegen Palletsoorten (LOVPRA).

Bij een Palletsoort kan worden aangegeven hoeveel Standaard Verschijningen (SV) er op een Pallet kunnen en in welke Palletsoort
deze moet worden uitgedrukt. Stel een Blokpallet bevat 150 SV en verwijst naar Blokpallet (dus 1:1)
Een SkidXl bevat 180 SV en uitgedrukt in Blokpallets zijn dit er 180/150 = 1,2
Als er dus 1 SkidXl wordt gebruikt, kan dus worden gezegd dat het het volume van 1,2 Blokpallets betreft.

De Palletsoort waarbij is aangegevens dat het de Standaard Pallet is, wordt gezien als de 'Blokpallet'.

Een Palletsoort kan worden opgenomen bij een Afleveradres om aan te geven dat het betreffende Afleveradres gebruik maakt van deze
Palletsoort. Is bij het Afleveradres een Palletsoort bekend, dan zal deze als default worden meegenomen bij het Toevoegen van een Verkooporderregel
voor het betreffende Afleveradres.

Bij de aanwezigheid van de Module Profit-Layout kan middels de Layout-Variabelen xx-WKAANTPAL en xx-BLOKPAL het werkelijk aantal
Pallets (o.b.v. de Pallet bij de Verkooporderregel - of indien deze daar onbekend is o.b.v. de Standaard Pallet) en het daaruit volgend
omgerekend aantal Blokpallets worden afgedrukt. (De xx kan bijvoorbeeld PB of VB zijn, afhankelijke van het af te
drukken dokument.)

Voor het berekenen van het werkelijke aantal Pallets zijn de volgende gegevens nodig :

- De Palletsoorten.
- Lengte, Breedte en Hoogte van de Verschijningsvorm.
- Bedrijfsparameters - Expeditie - 'Volume Faktor Standaard Verschijningsvorm' en 'Aantal Standaard Verschijningsvormen (SV) op
  Blokpallet'.

Is een van deze gegevens niet bekend, dan kan het aantal Pallets niet worden berekend!

Voorbeeld :
Bedrijfsparameter 'Volume Faktor SV' 0,018
Bedrijfsparameter 'Aantal SV op Blokpallet' 150
Verkooporderregel voor 300 Verschijningen met als Palletsoort 'PX' en Verschijningsvorm 'VX'.
Op Palletsoort 'PX' passen 120 SV (Standaard Verschijningen).
Lengte/Breedte/Hoogte Verschijningsvorm is 0,3 / 0,5 / 0,15

Volume Verschijningsvorm omrekenen naar het volume van een Standaard Verschijningsvorm :
 ((0,3 * 0,5 * 0,15) = 0,0225) / 0,018 = 1,25

Aantal Pallets 'PX' bepalen (= 'werkelijk aantal Pallets') :
 (300 * 1,25) / 120 =  3,125

Omrekenfaktor van Pallet 'PX' naar Blokpallet bepalen :
 120 / 150 = 0,8

Omrekenen aantal Pallets 'PX' naar Blokpallets :
 3,125 * 0.8 = 3,90625 -> afgerond wordt dat 4 Blokpallets.


N.b.: Bij meerdere Verkooporderregels worden eerst de afzonderlijke
aantallen werkelijke Pallets bij elkaar geteld alvorens het aantal Blokpallets wordt berekend.

Zie eveneens de Help-tekst bij de Rubrieken bij de Bedrijfsparameters Expeditie.

SYDV gereorganiseerd. Upgrade gaat weer verder.

Opgelost en staat bij je op het systeem.

Toevoegen Verkooporderregel moet zijn opgelost. Even opnieuw opstarten van Profit om zeker te weten gebruik te maken van de nieuwe programmatuur.

Hallo Mdekraa,

wat gaat er fout bij de Orderbevestiging?

Tovi,

e.e.a. is aangepast en staat bij je op het systeem.

Hallo Tovi,

dit veld zou je gewoon moeten kunnen benaderen, dus als dat niet lukt graag een voorbeeld waarbij je wel het veld ziet, maar waar deze niet benaderbaar is. Als je bedoeld "Dit veld zou ook nog achteraf muteerbaar moeten zijn (dus ook als order al status G heeft)" kan ik zeggen dat ik inderdaad daar geen rekening meer mee gehouden heb. Dus dit zal er nog bijgemaakt moeten worden. In gevallen dat een P.O. gereed gemeld is, kom je niet in LOPOWY terecht maar kom je in LOPOWY1 (beperkt wijzigbaar) terecht en daar is de Rubriek (nog) niet opgenomen. Maar gezien jouw verzoek zal hij daar ook opgenomen moeten worden.

Hallo Pascal,

Indien bij de Verkooporder Dkk-regels opgenomen zijn, mag het Afleveradres niet gewijzigd worden. Bij deze Order staat ook een DKK-regel en hierdoor mag het Afleveradres dus ook niet gewijzigd worden.

Hiervoor zijn de Funktie's achteraf overgezet, dus het zou nu niet meer voor mogen komen met latere Ordernummers dan die van 05-05-2009.