Releasenotes Kundtest, Integrationsförnyelsen, PI2

Målmiljö: BETA

Releasedatum: 2019-03-11

Åtgärdat

Kvantitet råvara

En första ISS 2.5 version som innehåller delar av den kommande ISS 3.0 versionen.

Destineringsunderlag

Går nu hela vägen ut till papiNet.

ForestloggingInstruction (Produktionsunderlag)

Rätt version av schema är numera angivit i papiNet-dokumentet
(ServiceInstructionV2R40_20181027_alpha_2018-10-29 istf ServiceInstructionV2R40_20180323_beta som är ett gammalt schema).
Detta fel var stoppande för de kunder som validerade mot det schema vi angivit i dokumentet.

Förstaledskontrakt

Rättat kodfel i mappning PapiNet som kunde ge ohanterade null fel. Lättare för ICC att felsöka när kunder skickar in felaktiga värden. Ingen skillnad för kund då det fortfarande inte går ut någon negativ BA när man skickar in felaktiga värden.

Går att skicka in ett förstaledskontrakt via papiNet. Nytt fält Alternativt måttslag med i ny ISS version. Går att få ut ett förstaledskontrakt där säljaren är privatperson (bugg 53102 hos AX)

Avtalsobjekt

Mappning ut kring EndradTidpunkt/SkapadTidpunkt så det stämmer med ISS mappningsdokument. Mappning av Stickväg så det skickas vidare till AX med null om det är ingen tagg finns i PapiNet XML Mappning PapiNet hanterar SupplyPoint utan SupplyPointDescription

PGPI (Routing)

Nya och ändrade PGPIer

Sortimentstruktur

Mappningskod i PapiNet hanterar Produktlistor utan produkter

Produktionsunderlag

Går nu att skicka in från papiNet. Business Ack kommer ut.

Business Ack

DocumentHistoryNumber finns inte längre med som tagg i papiNet-meddelandet.

Adapters Mq Inbound

Meddelanden som skickas på felkö får formatet MQSTR och inte MQHRF2

POC av det generella integrationsflödet

POC:en av det generella integrationsföldet omfattar endast köparekontrakt/Trading Contract i PI2. På teknisk nivå innebär det att IN- och UT-flödet för köparekontrakt tar en annan väg än tidigare men för “konsumenter” av IP ska det inte vara någon större skilland.

Men det finns dock skillnader:

  • Inga dubbletter skickas till prenumeranter
  • Interna system (endast BI i fallet för köparekontrakt) måste prenumerera för att få data

Att inga dubbletter skickas är den största förändringen. Definitionen för en dubblett är enkelt uttryckt att ett dokument skickas fler än en gång till samma endpoint. Detta scenario kan uppstå när en aktör prenumererar på exempelvis köparekontrakt i egenskap av olika roller och aktören sedan förekommer i flera olika roller i ett köparekontrakt.

I det scenariot kommer IP idag att välja endast en (1) av de aktuella prenumerationerna och valet är slumpmässigt. I praktiken innebär det att PartyType i ReceiverParty blir icke-deterministiskt.

<ReceiverParty PartyType=”Supplier”> <!– Värdet i PartyType är beroende av vilken prenumeration som (slumpvis) valts –>
<!– Övriga ReceiverParty-taggar har utelämnats –>
</ReceiverParty>

⚠️ Detta kan komma att ändras då specifikationen för prenumerationer är under arbete.

POC:en implementerar f ö inte det generella integrationsflödet fullt ut men är ett första steg mot målbilden. Det är även ett nödvändigt steg för att bl a kunna skicka en negativ kvittens när något går snett inom IP (vilket är nästa steg i POC:en).

Utfasat

N/A

Borttaget

N/A

Kända avvikelser

Generella avvikelser

  • Negativ Business Ack kommer inte ut om dokumentet fastnar i integrationsplattformen (dvs inte når affärssystem)
  • Negativ Business Ack kommer inte ut om det är fel på ett nytt dokument/objekt som inte tidigare finns i Klienten. (bugg hos AX, negativ BA kan bara skapas på förändringar)
  • Prenumerationer för Köparekontrakt visas felaktigt i Admin.

Då vi kör en poc på på nya versionen av IP så kan man inte se vilka prenumerationer som är upplagda för KK i admin gränssnittet. De prenumerationer som visas är för gamla IP versionen och används inte av den nya. De nya prenumerationerna kan man bara se i databasen.

För usecase J, L och G finns diskrepanser mellan ISSer och XML-exempel. Detta kommer rättas under kommande leveranser då XML-exemplen uppdateras.

Use Case G – ISS Contract (TradingContract) – Public version 4.0

  • För alla Partys sätts alltid Name1 till ”N/A”
  • ReceiverParty, PartyType. BuyerAgent finns inte med som möjlig mottagare
  • BuyerParty, PartyIdentifierType. Vi mappar inte TradeRegNumber eller VATIdentificationNumber
  • Product.ProductDescription. Vi mappar inte denna just nu
  • AdditionalItemInfo, UOM sätts till None
  • Olika fältlängd IN/UT på PriceListId, går att skicka IN 20 tecken men UT finns begränsning på 6 tecken. (bugg 54546 hos AX).

Use Case G – ISS OtherDocument (BusinessChainInfo) – Public version 3.0

  • Documentstatus sätts alltid till Original

Use Case H – ISS OtherDocument(DeliverySource) – Public version 6.0

  • För alla Partys sätts alltid Name1 till ”N/A”
  • Inga adressuppgifter fylls i
  • DeliverySourceCharacteristics.DeliverySourceProperty.CodeValue.TextValue mappas idag inte om till korrekt kod. RegelverkOmvandlingstal.

Use Case H – ISS Contract (OriginalContract) – Public version 8.0

  • För alla Partys sätts alltid Name1 till ”N/A”
  • Common contact, ContactName sätts till till ”N/A”
  • RespondToParty. Agency inte implementerat än
  • AdditionalItemInfo, UOM sätts till None.

Use Case H – ISS ServiceInstruction(ProductDestiningInstruction) – Public version 3.0

  • RecieverParty, PartyIdentifier
  • För alla Partys sätts alltid Name1 till ”N/A”
  • ServiceInstructionNumber trunkeras om längre än 30 tecken
  • LocationInfo.LocationParty.Partytype hanterar bara LogginArea.

Use Case K – ISS OrderConfirmation – Public version 3.0

  • OrderConfirmation.OrderConfirmationHeader.OrderConfirmationReference skall fyllas i ISS BusinessAcknowledgement – Public version 4.0
  • För alla Partys sätts alltid Name1 till ”N/A”
  • Negativ BusinessAck kommer inte ut ifall det berör ett dokument som inte finns i Klienten. (bugg hos AX)
  • Ingen BusinessAck kommer ut för Destinera Sortiment IN (bugg 53264 hos AX)

UseCase K- ISS LoadTender-PreBooking

  • Går inte att skicka in Transportunderlag, nya obligatoriska fält har lagts till i AX och utveckling är ej startad för motsvarande i PapiNet

Use Case L – ISS MeasuringTicket-MeasuringTicket-Product – Public version 2.0

  • Det måste alltid finnas en kontraktskedja. Känd bugg
  • För Quantity och QuantityInformation på alla ställen i ISS:en så gäller att om ingen matchning lyckas mot kodboken skapas ej nivån
  • MeasuringTicket.MeasuringTicketSequence.MeasuringTicketSequenceLineItem.AdditionalItemInfo.Code. Hanterar endast kvantitetprodukter där kvantitetstyp är Netto
  • MeasuringTicket.MeasuringTicketSequence.AdditionalItemInfo.Code.Hanterar endast kvantitetleverans där Kvantitetstyp är Brutto
  • Det är delvis implementerat delar av ISS version 3.0 men det innebär bara att det kan komma med fler uppgifter än de som finns i ISS version 2.0
  • Kvantitetstyper från AX som inte har någon motsvarighet i kodboken sätts till Vrak
  • Alla mätvärden utom de med metverden.metegenskapstyp = ”bruttovolym_m3f” eller ”bruttovolym_m3s” filtreras bort.