M3 tip: Omklassificering. PAS PÅ!!!

Når man anvender batchstyringsmetode 2, 3 eller 5, hvor der oprettes 'batchmaster' (MMS235), så vil information om varernes status findes på denne batchmaster:

Dette betyder (normalt), at hvis man vil omklassificere en del-mængde af en beholdning på et batchnummer, så skal man give denne delmængde et nyt batch-nummer.
Eks: 
- En beholdning på 1000 stk. af varenummer X med batchnummer 12345678
- De 100 stk skal kasseres, så de omklassificeres til nyt batchnummer, og til status 3
- Så har vi 900 stk. liggende på det oprindelige batchnummer i status 2
- Og vi har 100 stk. liggende på et andet batchnummer i status 1
- Og i MMS235 vil der nu findes begge batchnumre, med hver sin status.

I M3 10.1 er der imidlertid nu kommet muligheden for, at man kan ændre status på en del-mængde af en beholdning, uden at ændre batchnummer.

Det skal man ikke gøre!!

Normalt vil status-feltet (inde på billede E) været spærret, hvis man vælger en konkret del-mængde ved at angive lager, lokation, container.
MEN: Med denne nye parameter åbnes mulighed for, at man kan 'udpege' en bestemt beholdning på en lokation (og måske container), og så skifte status kun på denne delmængde.

Umiddelbart går det godt:
- Beholdningen får sin nye status (typisk 1 eller 3), fordi der er noget i vejen med den.
- Og 'Ny saldo' i transaktionshistorikken (MWS070) opdateres fint for hver statuskode.

MEN MEN MEN:
Der er fundet flere situationer, hvor M3 slet ikke kan håndtere denne situation, fordi beholdninger på samme batchnummer nu har forskellig status..

Følgende er observeret:- Hvis man laver en lokationsflytning af en beholdning, så skifter den automatisk status.
- PMS050 (lagerlægning fra produktion) kan ikke håndtere, at man lagerlægger i en status, der ikke passer med status i MMS235. (SÅ her er der stadig den 'gamle' spærring')
- Til gengæld kan man godt lagerlægge fra PMS050MI, selv om status afviger.
- Og vi har oplevet, at man lagerlægger en ny beholdning i status 2, men hvis batchens status i MMS235 er 1, så kan den nye beholdning (som har status 2) ikke gøres allokerbar.

Fejlmeldes til Infor.

Generelt tip: Programmer til screen shots

Gennem tiden er jeg stødt på forskellige programmer, der kan danne screen shots, som typisk anvendes i alle former for dokumentation.
De kan alle grabbe vinduer, eller firkantede udklip, og de kan sende output til clipboard eller til jpg-fil. Men der er også forskelle:


Her er et par oplagte muligheder:


SnagIt

• Pris: € 48
• Link: SnagIt
• Effektivt, men dyrt. Kan nærmest det hele. (Og kan også grabbe video'er)

Gadwin PrintScreen

• Pris: Gratis!
• Link: Gadwn Printscreen
• Ikke mulighed for annoteringer

Gadwin PrintScreen Pro

• Pris: $ 25
• Link: Gadwn Printscreen
• OK annoteringer med tekst og grafik
• (Dog har det altid ærgret mg, at der ikke er linier med pile. Dem skal man selv 'tegne')

FastStone Capture

• Pris: $ 20
• Link: FastStone Capture
• Gode annoteringer. Og så kan man lave kanten, så det ligner et afrevet stykke papir.
• Masser af output-muligheder: Direkte til printer, mail, Web, Word og meget mere.
• Min nye favorit!!

M3 tip: Opret en underleverandør-operation på en åben produktionsordre

I M3 fungerer underleverandør-operationer (ULEV) elegant og effektivt, hvis de vel at mærke er defineret i stamdata.

Men har du nogensinde forsøgt at oprette en ekstra ULEV-operation på en åben produktionsordre (PO)?

Det er jo nemt nok at tilføje en ekstra 'almindelig' operation på en åben PO, men en ny ULEV-operation skal jo hænge sammen med indkøbs-modulet, så man rapporterer den ved at varemodtage den tilknyttede indkøbsordre (IO), præcist som det sker for ULEV-operationer, der  er defineret i stamdata.

Men det burde jo være nemt nok, og det er det (næsten) også.

1. Sørg for at stamdata er klar: Planlægningsgruppe, leverandør, ULEV-IO-type osv.

2. Opret operationen på den åbne PO. (Ikke noget specielt her)

3. Opret indkøbsordren. (Og nu begynder bøvlet)

     Man kan ikke oprette ULEV-IO i PPS200.

     (Meddelelse: En indkøbsordre til underleverandør kan ikke registreres i PPS200. Brug PPS170 i stedet.)

     Nå, så må vi prøve PS170, og oprette manuelt med F17

     PPS170/A: Husk Tjenesteproces=Strukturtype, Tjeneste=Operationsnummer (4 decimaler)

     PPS170/E: Husk ULEV-ordretype, korrekt antal og pris.

     PPS170/F: Og så knækker filmen! Felterne til 'Ref. ordrenummer' er låst :-(

Ja, af uforklarlige årsager, så kan man ikke indtaste et ref.ordrenummer, når man har valgt en ULEV-ordretype. (OG det er jo her, at det er mest relevant.)

Løsning:

     I PPS170/E vælges en 'almindelig' ordretype. 

     Så kan man i F-billedet få lov til at indtaste ref.ordrenummer (kategori=1, ordre/opr.nr.).

     Og til sidst går man så ind i E-billedet igen, og ændrer til ULEV-ordretypen.

Så vil ULEV-operationen opføre sig som den skal, og man kan rapportere ved at varemodtage indkøbsordren.

Bemærk: Da det jo er en ekstra operation, så skal man ikke tænke på varen kostpris, men efterkalkulen vil derimod afspejle, at man har haft de ekstra-omkostninger, som kommer fra den ekstra operation.

M3 tip: SQL: Find gældende kostpris på en given dato

Mange steder i M3 skal man finde de gældende data ud fra gyldighedsdatoer.

Det kan være styklistelinier, salgspriser, kostpriser mv.

For eks. styklistelinier sørger M3 selv for, at skrive en 'Gyldig Til'-dato på en gammel linie, når der oprettes en ny, så man vil altid kun finde én linie, hvis man selekterer på en dato mellem 'Fra-' og 'Til-'datoerne.

Men for kostpriser er der ingen 'Gyldig Til'-dato, så her skal man selektere på den seneste 'Gyldig Fra'-dato.

Dette klarer M3-programmerne jo fint, men når der skal laves udtræk, så er det (kun) lidt bøvlet.

Eksemplet herunder viser, hvordan man kan finde en vares gældende kostpris pr. dags dato (her 2012-08-02).

select kofaci, koitno, kostrt, kopctp, kopcdt, kocsu3

 from mchead t1

 where kocono=1 and kofaci='001' and koitno='10000' and kocroc=0 and kopctp=3

 and kopcdt in

  (select max(kopcdt) from mchead t2

  where t2.kocono=1 and t1.kofaci=t2.kofaci and t1.koitno=t2.koitno and t1.kostrt=t2.kostrt and t1.kocroc=t2.kocroc and t1.kopctp=t2.kopctp

  and t2.kopcdt<=20120802

  group by t2.kocono, t2.kofaci, t2.koitno, t2.kostrt)

Metoden er, at der laves en grupperet sub-select, hvor man finder den 'største' 'Fra-dato', som er mindre end den valgte dato, og så sørger for, at kalkuledatoen skal være lig denne.

Med denne simple SQL får man også oplysning om, hvilken dato denne gældende kostpris er kalkuleret.

(I eksemplet forudsættes det, at kostprisen findes i kalkuletype 3 og sumniveau 3, og vi finder kostprisen for vare '10000' på facility '001')