Sales Interface - Implications in POS-DM

[Former Member]

Hello,

We have a tight timescales of implementation, so we want to keep the interfaces as simple as possible.

I have 4 questions to the experts.

1. The current sales interface from the 3 rd party POS to SAP includes a lot of logic around VAT and discounts to apply the appropriate discounts and tax to the supplied item values. As the new to be created Interface can supply the gross value after discounts have been applied and SAP can determine the amount of VAT given this gross value and the article VAT classification. It was suggested that the sales interface could operate without the discount and VAT information.

1. Question :    To determine what are the implications in

SAP POS DM and the downstream processing, such as WPUBON IDOCs to ECC, would be of omitting discount and VAT data in the sales interface? 

2. We need to determine whether we need to create two POS DM transaction item rows for a void transaction or can a void be done in a single row?

3. For the Tender element of a transaction, what is the implication of the means-of-payment subcategory being set to A or B?

4. For the totals interface, it was suggested that the Tender totals data in the current interface is is not used and therefore does not need to be mapped  in the new interface. Will this not affect the downstream POS DM processing?

All in all : Are our assumptions valid about the data we do not believe that we need to map in the new Interface, such as discount details

Many Thanks & Regards for the quick response!

Dharsi

[vikrant_mohite]

Hi,

Please find answers at

Thanks,

Vikrant.

[murtaza_dharsi2]

Hi Vikrant,

Many Thanks!

Do you have any POS-DM Training material that you could share?

Dharsi

[vikrant_mohite]

Hi,

You may check 778 – SAP POS Integration: POS DM Configuration.

Thanks,

Vikrant.

[murtaza_dharsi2]

Hello experts,

For my clarity and confirmation could you please let me know

1. If we remove Discounts and Tax from consideration in our interface (hence export from 3 rd party POS and remove the logic that Back Flushes Discount and Tax? (Tax being created in ECC when the WPUUMS document is processed)

2. Does this mean that the 3 rd Party need not to do any further development for the Line Void and this can be handled as a single row in our interface  and interface logic? (Currently we deal with positive and subsequent negative row.

3. on the Subcategory we already have set to "B" in the change Scenario.

    Are there implications to changing it or, should we leave it as "B"in the Change Scenario and ensure we keep that piece of logic in the interface build or remove it?

We need to be very clear in order to minimize effort.

Many Thanks.

[murtaza_dharsi2]

Hi Vikrant,

The aggregation logic is carried out in functions YPOSDM_TASK_SALES_AGGREGATION and YPOSDM_TASK_TOTAL_AGGREGATION . I  don’t see anything restricting this to the last 14 days transactions, Could it be a POS DM setting ? Can you please confirm?

Thanks!

Murtaza

[vikrant_mohite]

Hi,

Can you please elaborate.

Thanks,

Vikrant

[murtaza_dharsi2]

Hi Vikrant,

The 14 day logic is in the YCO_TILLS IDoc processing function YCO_TILLS_IDOC_INPUT. I thought it was on the BW side and it’s in ECC.

The logic for this is that if there is exactly one unconfirmed YCO_TILLS record in the last 14 days for the specified site, shift and cashier then the IDoc date will be changed to the date on this record, otherwise it will be left with the date that was passed from POS DM.

So, Thanks, that is sorted now.

[murtaza_dharsi2]

Hi Vikrant,

Would like to know how the dates are applied to IDocs/ data combined on multiple Posting Date entries in POSDM. Appreciate of your input/feedback.

Thanks!

[vikrant_mohite]

Hi,

What aggregation period are you using?

Thanks,

Vikrant.

[murtaza_dharsi2]

Hi Vikrant,

We are using a

BAdI: Implementation of Posting Date Determination from Aggregation Period.

[vikrant_mohite]

Hi,

Check with your technical consultant. It is Z implementation and not standard.

Thanks,

Vikrant.

[murtaza_dharsi2]

Thnaks, Vikrant! It is indeed Z Implementation.

Can you please share with us Test Scripts to Test the POS and the Interfaces?

[vikrant_mohite]

Difficult for Z*.

[suraj_pabbathi2]

Hi Murtaza,

I would like to take one question at a time. When you think you got the answer, I will take the next question.

Q1) To determine what are the implications in SAP POS DM and the downstream processing, such as WPUBON IDOCs to ECC, would be of omitting discount and VAT data in the sales interface?

Downstream impact, if you are planning to distribute the sales data to BW (or any analytic tool), you would loose tax information.

WPUBON idoc can translate the transactions and post into ECC. If there is no tax amount in Transaction, it will not carry tax and everything remains simple to work as expected.

I am wondering, w/o tax, how would you validate transaction. For eg: if sale amount is 50, tax is 5, total amount is 55. During auditing, the means of payment will be 55, if tax is not mapped, it will run into out of balance transaction, how you will handle this?

Thanks,
Suraj Pabbathi

[suraj_pabbathi2]

Hi Dharsi,

3. For the Tender element of a transaction, what is the implication of the means-of-payment subcategory being set to A or B?

Means of payment should be set for A which means payment, it should never be 'B' (credit memo).

Thanks,
Suraj Pabbathi