bureauofthefiscalservice / federalfinancialmanagement

Creative Commons Zero v1.0 Universal
1 stars 18 forks source link

040 - Procure-to-Pay #8

Open ghost opened 6 years ago

ghost commented 6 years ago

Thank you for your feedback on the data elements. We will consider your feedback as we continually assess how we can improve data definitions. This is the place to leave your feedback and questions about the following data elements: • GoodsAndServicesAcceptanceDate • PaymentTermsText • CurrentValueOfFundsRate • DeliveryDate • InvoiceReceiptDate • AdditionalPenaltyPaymentAmount • LateInterestPenaltyPaymentAmount • AcceleratedPaymentIndicator • OfferedDiscountRate • DiscountDate • DiscountTakenAmount

Also, after reviewing these elements and the selected DAIMS and Fiscal Service Data Registry elements, if you believe that there are data elements that have been excluded from this end-to-end business process, please comment here as well. The feedback period for these elements closes on 2/16/2018.

WVincent1 commented 6 years ago

Two of the 27 data elements (i.e., DeliveryDate, GoodsAndServicesAcceptanceDate) conflict with the standard ASNI EDI 856 approach that G-Invoicing is taking for Performance related transactions. The EDI standards call for two data elements (Date and Date Qualifier) to report the same information. For example, Delivery Date would be supplied as a date, accompanied by DateTimeQualifier of ‘Delivery’. The same would work for Acceptance Date with the DateTimeQualifier being ‘Acceptance’. Following this industry standard allows us to capture additional dates (e.g., Estimated Delivery, Receipt) without adding additional data elements for each performance step. (There are hundreds of DateTimeQualifiers established for the EDI 856 transaction). G-Invoicing has proposed to the agency community (via the Intragovernmental Transaction Working Group) that we use the terms PerformanceDate instead of Date and TransactionType instead of DateTimeQualifier to make these two data elements more clear, but the application remains of the two the same.

rwoods5525 commented 6 years ago

I am an Accountant within the P2P domain, so i will be addressing these elements only. Most of these Procure to Pay elements are already captured within our Oracle application, but there are a few that would have to be addressed by the Oracle Federal Development team. In general I agree these are FM related elements and should be standard across government. There are a few other things im not sure should be addressed here or will be pulled in a later phase.

  1. Most of the Procure to Pay elements added are from PPA. There are payments that fall outside of scope of Prompt Pay, so I dont know if there should be an indicator flag of somesort at the transactional level to capture if all these other are applicable or not.
  2. Also alot of these PPA data elements also relate very similarly to FAR elements. Are contract line item, ship to locations, period of performance/service dates, etc going to be tied into this at somepoint? There is a FAR case out there right now to standardize CLINs so just thought I would bring it up as food for thought.

FAR, PPA, and SAM.GOV all interlock in their language/references and with most of these being previously addressed via DATA Act.

jsclafan commented 6 years ago

What is the difference between this new data element, Delivery Date and the Received date ? Are you trying to distinguish between the date an agency receives a delivery at its Receiving Dock versus the date that the Program Manager actually receives the goods delivered, which may be at a later date.

WVincent1 commented 6 years ago

Good Afternoon,

Good question. The date/time field being proposed could represent almost anything, including delivery, receipt or any of the 1112 other date/time qualifiers for the EDI 856 transaction. Instead of associating several different dates to a single transaction (e.g., an order or invoice), the concept behind the EDI 856 is to allow a separate transaction to be reported for any procurement of fulfillment event related to that same order or invoice. It’s a different (more flexible) way to report the same information, one not requiring any data element changes, as long as the need is contained within the 1114 possibilities already supported by the EDI 856.

Wes Vincent, Accountant Bureau of the Fiscal Service FASO/OSD/OSB2 (304) 480-6084

From: jsclafan [mailto:notifications@github.com] Sent: Monday, February 26, 2018 1:33 PM To: bureauofthefiscalservice/federalfinancialmanagement federalfinancialmanagement@noreply.github.com Cc: Wesley D. Vincent Wesley.Vincent@fiscal.treasury.gov; Comment comment@noreply.github.com Subject: Re: [bureauofthefiscalservice/federalfinancialmanagement] 040 - Procure-to-Pay (#8)

What is the difference between this new data element, Delivery Date and the Received date ? Are you trying to distinguish between the date an agency receives a delivery at its Receiving Dock versus the date that the Program Manager actually receives the goods delivered, which may be at a later date.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://hyperlink.services.treasury.gov/?origin=https://github.com/bureauofthefiscalservice/federalfinancialmanagement/issues/8#issuecomment-368601605, or mute the threadhttps://hyperlink.services.treasury.gov/?origin=https://github.com/notifications/unsubscribe-auth/Ai-daAdyd9FD2U93SsJqZMqInVn43jTOks5tYvjSgaJpZM4RoPjy.

FIT4U commented 6 years ago

Is the original requirement for Accelerated Payment under the Recovery Act still in play? Isn't AcceleratedPaymentIndicator already me through item types of discount terms? Wouldn't it be possible that if accelerated payments needed to be issued in the future, we ask that the vendors represent this as a discount term on their invoices? Recommend delete.